46:"/_next/static/chunks/33yus346z0l_n.js" 47:"/_next/static/chunks/1r8ezocsukqp8.js" 48:"/_next/static/chunks/0iv56yrji_20j.js" 49:"/_next/static/chunks/0wa9m1-tphf9u.js" 4a:"/_next/static/chunks/08cuqqn_f60pp.js" 4b:"/_next/static/chunks/3zdsl3f9b0--r.js" 4c:"/_next/static/chunks/2j22cxchii_xx.js" 4d:"/_next/static/chunks/3bgoyiso1rhn7.js" 4e:"/_next/static/chunks/01a-3hvnqu8wl.js" 4f:"/_next/static/chunks/3m1xjj5kw5fie.js" 50:"/_next/static/chunks/0om3fkgfnicab.js" 51:"/_next/static/chunks/0gafyzg9j9yqj.js" 52:"/_next/static/chunks/20w4eaqlekefm.js" 53:"/_next/static/chunks/449--h5z1s6nq.js" 54:"/_next/static/chunks/3k2gyg36fnag_.js" 55:"/_next/static/chunks/18ggtgz2yf759.js" 56:"/_next/static/chunks/0hlb44ca7-4a2.js" 57:"/_next/static/chunks/253gnmj0-cj17.js" 58:"/_next/static/chunks/09nq57stwzkgf.js" 59:"/_next/static/chunks/082jo-0ajazgr.js" 5a:"/_next/static/chunks/2ozcrjb_hh74t.js" 5b:"/_next/static/chunks/05i8en-x14ibi.js" 5c:"/_next/static/chunks/32izpn90gvm22.js" 5d:"/_next/static/chunks/0jbzid2v9xv3h.js" 5e:"/_next/static/chunks/0i3-eynrkvqi7.js" 5f:"/_next/static/chunks/1tn-0fivsxsv1.js" 60:"/_next/static/chunks/34h36hyf_ggow.js" 61:"/_next/static/chunks/20329i6m_04t6.js" 62:"/_next/static/chunks/161uxd62cjny2.js" 63:"/_next/static/chunks/2k8pepwc4pxns.js" 64:I[593304,["$2b","$2c","$2d","$2e","$2f","$30","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61","$62","$63"],"OwnedHydration"] 65:T48e,Imagine a high-frequency trading platform where a 10-millisecond delay costs millions of dollars. Consider an autonomous vehicle navigation system where a 100-millisecond lag in processing sensor data could mean the difference between a safe lane change and a catastrophic collision. Think about a multiplayer gaming server where 50 milliseconds of additional latency transforms a responsive, immersive experience into an unplayable, frustrating mess. **These aren't hypothetical scenarios—they represent the daily reality of real-time system engineering.** In traditional distributed systems, we optimize for throughput, availability, and eventual consistency. We accept that operations take "as long as they take" and design around asynchronous processing, retries, and graceful degradation. But real-time systems operate under an entirely different paradigm: **time itself becomes a first-class constraint**. This page establishes the foundational understanding of what makes a system "real-time," exploring the formal requirements, mathematical models, and engineering constraints that separate real-time architectures from conventional distributed systems.66:T5f7,**Real-Time Operating Systems (RTOS):** General-purpose operating systems like Linux, Windows, and macOS are designed for throughput and fairness, not real-time guarantees. They include features that make timing unpredictable: - Preemptible kernels that can delay high-priority user tasks - Complex I/O scheduling that optimizes for throughput - Memory management that may trigger page faults at any time - Background processes that consume unpredictable resources Real-Time Operating Systems (RTOS) like VxWorks, QNX, FreeRTOS, and RTEMS are specifically designed for timing predictability: - **Bounded interrupt latency** — Maximum time from interrupt signal to handler execution - **Priority-based preemption** — Highest-priority ready task always runs immediately - **Minimal kernel overhead** — Lean kernel code with predictable execution time - **Priority inheritance** — Prevents priority inversion when tasks share resources - **No virtual memory** (often) — Eliminates page faults in the critical path **The Linux RT_PREEMPT patch:** For systems that need Linux compatibility with improved real-time behavior, the PREEMPT_RT patch set converts Linux into a real-time capable system by: - Making the kernel fully preemptible - Converting spinlocks to sleeping locks - Moving interrupt handlers to kernel threads - Enabling priority inheritance for locks This provides "soft real-time" capabilities with latencies in the tens-to-hundreds of microseconds range, suitable for many industrial applications.45:["$","$L64",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792318377033,"state":{"data":{"json":{"id":"seed_952b164a6509407397ac9cc1364d6add","slug":"what-is-real-time","category":"System Design (HLD)","topic":"What Is Real-Time?","title":"Understanding Real-Time Systems","description":"Master the foundational concepts of real-time systems, from formal definitions and latency requirements to the critical distinction between soft and hard real-time guarantees. Learn when and why real-time architectures are essential for building responsive, mission-critical applications.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_f7c37d9bda51507c0830ac636c8ddd2f","title":"Real-Time Requirements","order":0,"content":[{"id":"opening-hook","title":"When Milliseconds Become Mission-Critical","content":[{"data":{"content":"$65"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the formal definition of real-time systems, recognize the key characteristics that distinguish them from traditional systems, grasp the mathematical foundations of timing constraints, and appreciate why temporal correctness is as critical as functional correctness in these domains.","variant":"info"},"type":"callout"}]},{"id":"defining-real-time","title":"Defining Real-Time Systems","content":[{"data":{"content":"The term \"real-time\" is perhaps one of the most misunderstood concepts in software engineering. Many developers equate \"real-time\" with \"fast\" or \"interactive,\" but this conflation obscures the true meaning and engineering implications of real-time computing.\n\n**The formal definition:**\n\n> A **real-time system** is a system in which the correctness of the computation depends not only on the logical correctness of the output but also on the time at which the output is produced.\n\nThis definition, established by decades of computer science research, captures the essential distinction: in real-time systems, **a correct answer delivered too late is a wrong answer**.\n\nConsider the contrast with conventional systems:"},"type":"text"},{"data":{"rows":[["Correctness criterion","Logical output correctness","Logical correctness + temporal correctness"],["Timing treatment","Best-effort, optimize for average case","Guaranteed bounds, worst-case analysis"],["Failure definition","Wrong output or crash","Wrong output, crash, OR late output"],["Design focus","Throughput, scalability, availability","Predictability, determinism, bounded latency"],["Resource allocation","Dynamic, on-demand","Pre-allocated, statically analyzed"],["Performance metric","Average latency, percentiles","Worst-case execution time (WCET)"]],"caption":"Real-Time vs. Conventional Systems","headers":["Aspect","Conventional Systems","Real-Time Systems"]},"type":"table"},{"data":{"content":"**Understanding temporal correctness:**\n\nTemporal correctness introduces a dimension that most software engineers rarely consider explicitly. When we say a system must respond \"in time,\" we're making a statement that can be formalized mathematically:\n\n- **Response time (R)**: The elapsed time from when a stimulus arrives to when the corresponding response is produced\n- **Deadline (D)**: The maximum allowable response time for a given stimulus\n- **Temporal correctness constraint**: R ≤ D for all invocations\n\nThis seemingly simple constraint—\"respond before the deadline\"—has profound implications for system design, resource allocation, scheduling algorithms, and failure handling."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Deadline Is Not Optional","content":"In real-time systems, missing a deadline isn't just a performance degradation—it can constitute a system failure. Unlike web applications where a slow response is merely inconvenient, real-time systems treat deadline violations with the same severity as logical errors or crashes. Your system architecture must be designed around this constraint from the ground up.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"anatomy-of-timing","title":"The Anatomy of Timing Constraints","content":[{"data":{"content":"Real-time systems are characterized by specific types of timing constraints that govern their behavior. Understanding these constraint types is essential for proper system design and analysis.\n\n**Types of timing constraints:**"},"type":"text"},{"data":{"items":["**Deadline constraints** — The response must be produced before a specified time after the triggering event. This is the most common constraint type. Example: \"Process the sensor reading within 10ms of receipt.\"","**Periodicity constraints** — Events occur at regular intervals, and corresponding processing must complete within each period. Example: \"Sample the temperature sensor every 100ms and process each sample before the next arrives.\"","**Jitter constraints** — The variation in timing must be bounded, even if average timing is acceptable. Example: \"Video frames must be rendered with no more than ±2ms variation to prevent visual stutter.\"","**Precedence constraints** — Certain operations must complete before others can begin. Example: \"The obstacle detection must complete before the path planning computation starts.\"","**Separation constraints** — A minimum time must elapse between events. Example: \"Allow at least 5ms between successive actuator commands to prevent mechanical stress.\""],"title":{"icon":"Target","text":"Fundamental Timing Constraint Types","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The timing constraint hierarchy:**\n\nReal-time systems typically involve multiple concurrent activities, each with its own timing constraints. These constraints form a hierarchy that the system must satisfy simultaneously:\n\n```\nSystem-level deadline (e.g., end-to-end latency < 50ms)\n├── Subsystem A deadline (e.g., sensor processing < 15ms)\n│ ├── Task A1 deadline (5ms)\n│ └── Task A2 deadline (10ms)\n├── Subsystem B deadline (e.g., computation < 20ms)\n│ ├── Task B1 deadline (8ms)\n│ └── Task B2 deadline (12ms)\n└── Subsystem C deadline (e.g., actuator control < 15ms)\n └── Task C1 deadline (15ms)\n```\n\nThe challenge lies in ensuring that meeting individual task deadlines also satisfies subsystem and system-level timing requirements, accounting for communication delays, resource contention, and scheduling overhead."},"type":"text"},{"data":{"icon":"Info","title":"End-to-End Latency Budgets","content":"In practice, system designers create latency budgets that allocate portions of the end-to-end deadline to individual components. This budgeting process requires deep understanding of component behavior, worst-case execution times, and communication overheads. Overestimating component latencies leads to overprovisioned systems; underestimating leads to deadline violations.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"determinism-predictability","title":"Determinism and Predictability","content":[{"data":{"content":"Two fundamental properties distinguish real-time systems from best-effort systems: **determinism** and **predictability**. While often used interchangeably, these concepts have distinct meanings in real-time computing.\n\n**Determinism:**\n\nA system is deterministic if, given the same initial state and the same inputs, it will always produce the same outputs in the same amount of time. Deterministic behavior means there is no randomness or unpredictable variation in system execution.\n\n**Predictability:**\n\nA system is predictable if its timing behavior can be analyzed and bounded before execution. A predictable system may not be strictly deterministic (there might be variation), but the bounds of that variation are known and can be guaranteed.\n\n**The relationship:**"},"type":"text"},{"data":{"rows":[["Determinism","Same inputs → same timing, always","Ideal but often impractical"],["Predictability","Timing bounds are known a priori","Essential requirement"],["Bounded variation","Max variation from expected timing is limited","Required for jitter-sensitive applications"],["Analyzability","Timing can be mathematically proven","Required for safety-critical systems"]],"caption":"Determinism vs. Predictability","headers":["Property","Description","Real-Time Requirement"]},"type":"table"},{"data":{"content":"**Sources of non-determinism in modern systems:**\n\nAchieving determinism in modern computing systems is challenging due to numerous sources of timing variability:"},"type":"text"},{"data":{"items":["**CPU caching** — Cache hits vs. misses cause order-of-magnitude timing differences. A cache miss can take 100+ CPU cycles compared to single-digit cycles for a hit.","**Branch prediction** — Mispredicted branches cause pipeline stalls. Modern CPUs can have 15+ pipeline stages, meaning mispredictions waste significant cycles.","**Virtual memory** — Page faults trigger disk I/O, adding milliseconds of delay. TLB misses add memory access latency.","**Garbage collection** — GC pauses can halt all application threads for milliseconds or longer. Even \"low-pause\" collectors introduce unpredictable delays.","**Operating system scheduling** — Context switches, interrupt handling, and kernel activity consume unpredictable CPU time.","**Network communication** — Network latency varies due to congestion, routing changes, and protocol behavior (TCP retransmissions, etc.).","**I/O operations** — Disk seeks, SSD garbage collection, and device driver behavior introduce timing variability.","**Multi-core interference** — Shared resources (memory bus, last-level cache) create contention between cores."],"title":{"icon":"AlertCircle","text":"Common Sources of Non-Determinism","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Designing for Predictability","content":"Real-time system designers don't eliminate non-determinism—they bound it. Techniques include disabling interrupts during critical sections, pinning processes to specific CPU cores, pre-allocating memory, using real-time operating systems (RTOS), and avoiding dynamic memory allocation during time-critical operations.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"wcet-analysis","title":"Worst-Case Execution Time Analysis","content":[{"data":{"content":"The cornerstone of real-time system analysis is **Worst-Case Execution Time (WCET)**—the maximum time a piece of code can take to execute under any possible input and system state.\n\n**Why WCET matters:**\n\nIn conventional systems, we often focus on average-case or typical-case performance. We might say \"this operation typically takes 5ms\" and consider optimization successful if we reduce the average. But in real-time systems, it's the worst case that determines whether deadlines are met:\n\n- If your deadline is 10ms and your WCET is 8ms, you can guarantee meeting the deadline\n- If your average is 5ms but WCET is 15ms, you cannot guarantee meeting the 10ms deadline, even though you \"usually\" succeed\n\n**Computing WCET:**\n\nWCET analysis uses two primary approaches:"},"type":"text"},{"data":{"left":[{"data":{"items":["Analyzes source code or binary without execution","Determines longest execution path mathematically","Models CPU pipeline, cache behavior, branch prediction","Produces provable upper bounds","Required for safety-critical certification","Often overestimates (safe but pessimistic)","Complex for modern out-of-order processors"],"title":{"icon":"Target","text":"Static Analysis","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Executes code with various inputs","Measures actual execution times","Uses statistical analysis to estimate bounds","More practical for complex systems","Cannot guarantee absolute worst case found","Often combined with static analysis","Widely used in industry practice"],"title":{"icon":"Zap","text":"Measurement-Based Analysis","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**The WCET challenge in modern systems:**\n\nModern processors are designed for average-case performance, not worst-case predictability. Features that improve average throughput often make WCET analysis harder:"},"type":"text"},{"data":{"rows":[["Out-of-order execution","Better CPU utilization","Harder to analyze execution order"],["Speculative execution","Hides memory latency","Introduces timing variability"],["Multi-level caching","Faster memory access (on average)","Cache state affects timing dramatically"],["Dynamic frequency scaling","Power efficiency","CPU speed varies unpredictably"],["Simultaneous multithreading","Better core utilization","Threads interfere with each other"]],"headers":["Feature","Benefit for Throughput","Challenge for WCET"]},"type":"table"},{"data":{"content":"For safety-critical real-time systems, architects may deliberately choose simpler processors with more predictable behavior, sacrificing average performance for timing guarantees."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The 10x Rule of Thumb","content":"In complex modern systems, the worst-case execution time can be 10x or more the average-case time. A function that typically executes in 1ms might take 10-20ms in the worst case due to cache misses, page faults, or GC pauses. Design your systems with substantial headroom, especially when formal WCET analysis isn't feasible.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"schedulability-analysis","title":"Schedulability Analysis","content":[{"data":{"content":"Once we know the WCET of individual tasks, the next question is: **can all tasks meet their deadlines when running concurrently on shared resources?** This is the domain of schedulability analysis.\n\n**The schedulability problem:**\n\nGiven:\n- A set of tasks, each with its own period, deadline, and WCET\n- A set of shared resources (CPUs, memory, I/O devices)\n- A scheduling algorithm\n\nDetermine: Will all tasks always meet their deadlines?\n\n**Rate Monotonic Scheduling (RMS):**\n\nFor periodic tasks with deadlines equal to their periods, Rate Monotonic Scheduling is optimal among fixed-priority algorithms. The classic schedulability test for RMS states that n tasks are guaranteed schedulable if:\n\n`U = Σ(Ci/Ti) ≤ n(2^(1/n) - 1)`\n\nWhere:\n- Ci = WCET of task i\n- Ti = Period of task i\n- U = Total CPU utilization\n\nFor large n, this bound approaches ln(2) ≈ 0.693, meaning you can guarantee schedulability with up to ~69% CPU utilization."},"type":"text"},{"data":{"rows":[["1 task","100%","U ≤ 1.000"],["2 tasks","82.8%","U ≤ 0.828"],["3 tasks","78.0%","U ≤ 0.780"],["5 tasks","74.3%","U ≤ 0.743"],["10 tasks","71.8%","U ≤ 0.718"],["∞ tasks","69.3% (ln 2)","U ≤ 0.693"]],"caption":"RMS Schedulability Bounds by Task Count","headers":["Number of Tasks","Utilization Bound","Guaranteed If Utilization Below"]},"type":"table"},{"data":{"content":"**Earliest Deadline First (EDF):**\n\nEDF is a dynamic priority scheduling algorithm that can achieve 100% CPU utilization while guaranteeing all deadlines are met (if the task set is schedulable at all). Tasks are prioritized by their absolute deadline—the task whose deadline is nearest runs first.\n\nEDF schedulability test (for periodic tasks where deadline = period):\n\n`U = Σ(Ci/Ti) ≤ 1`\n\nThis is the theoretical optimum: if total utilization exceeds 100%, no scheduling algorithm can guarantee all deadlines.\n\n**Practical considerations:**"},"type":"text"},{"data":{"items":["**Overhead matters** — Context switch time, interrupt latency, and scheduler overhead must be included in analysis. A scheduler that takes 1ms to make decisions adds 1ms to every task switch.","**Resource contention** — Shared resources (locks, I/O devices, memory bandwidth) can cause priority inversion and blocking. Priority inheritance protocols help but add complexity.","**Aperiodic and sporadic tasks** — Many real systems have event-driven tasks with irregular arrival times. These require more sophisticated analysis techniques.","**Multi-core scheduling** — Task assignment to cores, cache interference, and bus contention make multi-core schedulability analysis significantly more complex.","**Mixed criticality** — Systems often combine hard real-time tasks with soft real-time and best-effort tasks, requiring isolation and guaranteed resource allocation."],"title":{"icon":"Info","text":"Schedulability in Practice","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Leave Headroom","content":"Even when schedulability analysis says you can use 80% CPU utilization, prudent engineers target 50-60% in production. This headroom accommodates WCET estimation errors, unexpected load spikes, and future feature additions without requiring system redesign.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"real-time-stack","title":"The Real-Time System Stack","content":[{"data":{"content":"Real-time requirements affect every layer of the system stack. Unlike conventional systems where timing is a \"nice to have,\" real-time systems require timing guarantees at each layer to compose into end-to-end guarantees.\n\n**The layer-by-layer challenge:**"},"type":"text"},{"data":{"rows":[["Hardware","Maximize average throughput","Predictable timing, disable dynamic features"],["Operating System","General-purpose, fairness-focused","RTOS with priority scheduling, bounded latency"],["Runtime/VM","JIT compilation, background GC","AOT compilation, predictable memory management"],["Language","Dynamic typing, runtime dispatch","Static types, compile-time decisions"],["Libraries","Optimize for common case","Bounded-time algorithms, no hidden allocations"],["Application","Handle errors via exceptions, retries","Fail-safe defaults, pre-validated inputs"],["Network","Best-effort delivery, congestion control","QoS guarantees, traffic shaping, bounded latency"]],"caption":"Real-Time Considerations Across the Stack","headers":["Layer","Conventional Approach","Real-Time Approach"]},"type":"table"},{"data":{"content":"$66"},"type":"text"},{"data":{"icon":"Info","title":"Language Choice Matters","content":"High-level languages with garbage collection (Java, Go, Python) are challenging for hard real-time systems due to GC pauses. Languages like C, C++, Rust, and Ada are preferred because they provide explicit memory control. Some domains use specialized real-time garbage collectors or regions-based memory management to enable high-level languages with predictable timing.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"quantifying-requirements","title":"Quantifying Real-Time Requirements","content":[{"data":{"content":"Before designing a real-time system, engineers must precisely quantify the timing requirements. Vague requirements like \"the system should be responsive\" are insufficient—real-time design requires specific, measurable constraints.\n\n**The requirements specification process:**"},"type":"text"},{"data":{"type":"ordered","items":["**Identify time-critical operations** — Which operations have timing constraints? What triggers them (sensors, user input, external events, periodic timers)?","**Determine deadline sources** — Where does each deadline come from? Physical laws (control system stability), human perception (UI responsiveness), external contracts (SLAs), safety requirements?","**Quantify specific values** — What is the exact deadline in milliseconds or microseconds? What is the required frequency for periodic operations?","**Define acceptable failure rates** — For soft real-time, what percentage of deadline misses is tolerable? What is the maximum acceptable delay when deadlines are missed?","**Identify dependencies** — What must complete before a time-critical operation can start? What is the end-to-end latency budget?","**Document worst-case scenarios** — What system state causes maximum latency? How does degraded mode (hardware failures, overload) affect timing?"],"title":{"icon":"Target","text":"Steps to Quantify Real-Time Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Example: Video conferencing application requirements:**"},"type":"text"},{"data":{"rows":[["Audio capture latency","< 10ms","Human auditory perception; longer delays cause echo perception"],["Video capture latency","< 33ms","30fps frame timing"],["Audio encoding latency","< 15ms","End-to-end budget allocation"],["Video encoding latency","< 40ms","End-to-end budget allocation"],["Network transmission","< 100ms one-way","Conversational quality threshold"],["End-to-end mouth-to-ear","< 150ms","ITU-T G.114 recommendation for acceptable conversation quality"],["Jitter budget","< 30ms","Audio buffer sizing, visible stutter threshold"],["Acceptable audio glitches","< 1% of 10-second windows","User experience quality target"]],"headers":["Requirement","Value","Source"]},"type":"table"},{"data":{"content":"These specific values drive architecture decisions: buffer sizes, encoding algorithm selection, network protocol choice, and server placement strategy."},"type":"text"},{"data":{"icon":"AlertCircle","title":"When Requirements Are Unknown","content":"If stakeholders can't provide specific timing requirements, that's often a sign that the system isn't truly real-time—it's just \"should be fast.\" Push back on vague requirements. Real-time systems require explicit deadline specifications because they fundamentally change how the system is designed, built, and validated.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Real-Time Requirements","content":[{"data":{"content":"We've established the foundational understanding of what makes a system \"real-time.\" Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Real-time ≠ fast** — Real-time means timing correctness is part of correctness. A correct result delivered late is a wrong result.","**Temporal and logical correctness** — Real-time systems must satisfy both what they compute and when they compute it.","**Timing constraints have structure** — Deadlines, periods, jitter bounds, precedence relationships form a constraint hierarchy.","**Predictability over performance** — Real-time systems optimize for worst-case bounds, not average-case throughput.","**WCET is foundational** — Worst-Case Execution Time analysis underpins all timing guarantees.","**Schedulability determines feasibility** — Mathematical analysis proves whether a task set can meet all deadlines.","**Every layer matters** — Real-time guarantees require support from hardware through application code.","**Specific requirements required** — Real-time design starts with quantified, measurable timing specifications."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand what real-time requirements mean formally, the next page explores latency expectations in depth—examining how different domains require different levels of responsiveness, how latency is measured and characterized, and what latency budgets look like for real-world systems."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the formal definition of real-time systems and the key characteristics that distinguish them from conventional distributed systems. This foundation is essential for understanding the soft vs. hard real-time distinction, latency expectations, and the architectural patterns covered in subsequent pages.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_ead1f6c7bfd490897b3e6041c7ff1656","title":"Latency Expectations","order":1,"content":null,"isLocked":true},{"id":"seed_7097a7fd9ca13c6c616277f2193dfa2d","title":"Soft vs Hard Real-Time","order":2,"content":null,"isLocked":true},{"id":"seed_c26cb85f4525d5c87a1f437be9efba03","title":"Real-Time System Use Cases","order":3,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792318377026,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"what-is-real-time"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"what-is-real-time\"},\"type\":\"query\"}]"},{"dehydratedAt":1792318377035,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792318377031,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_952b164a6509407397ac9cc1364d6add"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_952b164a6509407397ac9cc1364d6add\"},\"type\":\"query\"}]"},{"dehydratedAt":1792318377035,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792318377033,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_ead1f6c7bfd490897b3e6041c7ff1656"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_ead1f6c7bfd490897b3e6041c7ff1656\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792318377035,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792318377033,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_ead1f6c7bfd490897b3e6041c7ff1656"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_ead1f6c7bfd490897b3e6041c7ff1656\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792318377035,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792318377033,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_ead1f6c7bfd490897b3e6041c7ff1656"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_ead1f6c7bfd490897b3e6041c7ff1656\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792318377035,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_ead1f6c7bfd490897b3e6041c7ff1656","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_ead1f6c7bfd490897b3e6041c7ff1656\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@67"}]},"children":"$L68"}]