# Real-Time, Near Real-Time, and Non-Real-Time Systems Part of the design process of complex systems is to define how they will execute tasks in time. There seems to be a lax approach in engineering domains about the “real-time” concept. Engineers tend to loosely use the term “real-time” when referring to other matters like high-performance computing (this means, executing things fast) or when talking about determinism. Real-timeliness has nothing to do with high-performance computing or determinism. The former is about piling up microprocessors in complex arrangements to execute more instructions per unit of time, whereas the latter is about particular inputs always producing the same [outputs](https://en.wikipedia.org/wiki/Deterministic_algorithm). Computing—whether it happens in a laptop, a tiny IoT sensor, or a deep space probe—is not only about the speed at which operations like moving data or calculations happen but also—and perhaps more importantly—about handling events. An event is a relevant mark in time that indicates that something _worth noting_ has happened: an external signal has changed state, a computation is over, a division-by-zero took place, a scheduled interrupt landed, or some data has arrived from a distant subsystem through some interface. Action or actions tend to follow an event. Real-timeliness—or the lack thereof—is all about how the computing system deals with such time-framed events, and how the system meets pre-defined deadlines between events. Computer-controlled systems handle events by using tasks that are user-defined subroutines mandated to execute at specific times, for a specific time, and with a specific priority. Mind you, tasks and threads are mechanisms provided by abstractions such as operating systems: a microprocessor knows nothing about them, but only about instruction pipelines, program counters, caches, interrupt handlers, subroutines, stacks, and context switching. Imagine you want the newspaper delivered every morning to your door. After you subscribe, they tell you that the paper will be delivered every day between 7 and 8 am. If you agree with this schedule, do you really care if the paper is delivered at 7:03:00am or 7:55:02 am? Probably not. But you do want the paper delivered every day; you wouldn’t like the guy to randomly skip your door every once in a while. If missing a delivery should happen, the most probable consequence would be a canceled subscription: unmet deadlines always carry consequences. In computing terms, this newspaper delivery service can be considered real-time. Now imagine the paper delivery service becoming very popular and, all of a sudden, all houses on your street sign up for it. And they all request the paper to be delivered at the same time slot as yours, from 7 to 8 am. Now the paperboy is overwhelmed delivering papers like there’s no tomorrow, and he soon starts to miss the 8 am mark. Unsurprising news: workload affects real-timeness. Is this a problem? It depends. If the paperboy says “Ma’am, things might take slightly longer than 8 am but I absolutely **guarantee** a paper will be at your door no matter what” then the system is still real-time, but has suddenly—and literally—softened: it turned into a “soft” real-time type. Still, no deadlines shall be missed, but time constraints might not be necessarily met. Many systems are fine with this behavior, for instance, systems in which delayed event handling will not cause any failure or damage but just a somewhat late response towards a user or another system. If an ATM takes 3 seconds to deliver the cash after choosing the amount to withdraw instead of, say, 2.5 seconds, nothing will happen and life will go on. If an Engine Control Unit (ECU) in a car delays by 0.5 seconds sending the electrical pulse to inflate an airbag, this may be the difference between life and death. Imagine you challenge your coworkers to a ping pong match during some break. A ping pong game is a great example of a _system_ where deadlines are supposed to be met and in due time, otherwise the whole thing breaks apart. A game of ping pong can only be considered so if both opponents meet their deadlines of hitting the ball with the paddle before it’s too late. There is some leeway where players can choose to hit the ball earlier or later,  but there are limits for both: you can’t hit the ball before it bounces once on your side, and you can’t hit it anymore once it’s passed your paddle line. ![[ping_pong.gif]] > [!Figure] > Yours truly playing ping-pong in non-real-time mode > [!question] Is ping pong “hard” or “soft” real-time then? Exercise for the reader[^1].  We briefly spoke about priorities before, and this cannot go unmentioned any further. The cause of a missed deadline can be a higher priority deadline preempting the current one. A microprocessor is ultimately executing one instruction at a time (before purists get triggered: ok, some sophisticated architectures may execute more than one instruction per cycle) therefore we as software designers must opportunistically prioritize subroutines to specify which deadlines are more important than other deadlines and which ones are tolerable and safe to go unmet. Needless to say, real-time computing systems must keep track of time. Mind this does not necessarily need to be in seconds or fractions of seconds but can be in system “ticks”, a tick being anything that can be counted and kept track of. If we want the system to react in times that are compatible and comparable with the way our human clocks track time, the ticks shall be somehow related to human clock seconds. There are also slightly more obscure flavors of schemes such as “near” real-time execution. Near real-time is a nebulous term that tends to be used in complex data-intensive situations where a heterogeneous amount of things like humans, artifacts, and systems are put in a daisy chain between data acquisition and delivery of processed data for user consumption. Near real-time tends to be a euphemism for “we don’t know how long it will take, but we’ll do our best”. Fair enough, as long as it’s clear for all parties involved. Last of specimens: non-real-time systems. The free spirits of the gang. A non-real-time system takes a very relaxed approach to deadlines: they might be missed, or not, it depends. It may take longer, or shorter, it depends. A routine or algorithm will eventually execute, but chill because they can’t sign any Service-Level Agreement here. And this is fine, to some extent and in some specific contexts. Consumer laptops are missing or rescheduling deadlines all the time, taking longer or shorter to do things depending on workload, for example depending on the number of tabs open in your browser, or during some heavy file import. But such is life: that’s what you signed up for when you bought it. One thing is for sure: you wouldn’t put your laptop to control your pacemaker or any other life-support system or auto-pilot an airliner. Care must be taken when coupling non-real-time systems with real-time systems. The success of such hybrid systems largely depends on knowing precisely who does what and the implications of missing the time marks. Examples of this are computer games running on non-real-time environments coupled with [[Semiconductors#Graphics Processing Units (GPUs)|GPUs]]. Or [SCADA](https://en.wikipedia.org/wiki/SCADA) systems where user interfaces (non-real-time) are coupled with distributed PLCs (real-time). As you can see, in this section we have not talked about speed of execution. Real-timeness is not about how fast a processor can run, but about how the processor handles events and commits to meet the due dates. A supercomputer cluster can execute in non-real-time. A [microcontroller with 68 bytes of RAM](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/30430D.pdf) running at an infinitesimal fraction of speed can be real-time and even play [ping pong](https://320volt.com/en/pic16f84-video-tv-oyun-tetris-ve-pong-joistik-kontrollu/). [^1]: Games, in general, can be considered soft real-time, where execution of deadlines is important to ensure gameplay, although the timing strictness does not need to be high. Computer games such as flight simulators must ensure “pseudo” soft real-time response due to the fact they tend to run on non-real-time environments; this means, that responses at the game/user level shall be ensured while at the low-level deadlines can be opportunistically lax.