Real-Time vs Near Real-Time vs Non Real-Time Systems
There seems to be a lax approach in engineering domains about the “real-time” concept. Engineers—and others—tend to loosely use the term “real-time” when referring to other matters like high-performance computing (this means basically executing things fast) or when talking about determinism.
Real-timeness has nothing to do with high-performance computing or determinism. The former is about piling up microprocessors in complex arrangements in order to execute more instructions per unit of time, whereas the latter is about particular inputs always producing the same outputs.
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 which 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-timeness—or the lack thereof—is all about how the computing system deals with such events, and basically how the system meets pre-defined deadlines between events. Computing systems handle events by using tasks which 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 at your door. After you subscribe, they tell you that the paper will be delivered every day between 7 and 8am. If you agree with this SLA, 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 to be delivered every day; you wouldn’t like the guy to randomly skip your door every once in a while. If missing a delivery should take place, the most probable consequence would be a canceled subscription: unmet deadlines always carry consequences. If no door-skipping is allowed, in computing terms, the newspaper delivery service can be considered real-time.
Now imagine the paper delivery service goes 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—understandably before going to work. Now the paperboy is overwhelmed delivering papers like there’s no tomorrow, and he soon starts to miss the 8am 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 guarantee a paper will be delivered at your door no matter what” then the system is still real-time, but has suddenly—and literally—softened: it turned “soft” real-time. 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 really happen and no one will ever notice. If an 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 for 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.
Is ping pong “hard” or “soft” real-time then? Exercise for the reader1.
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 in order 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 which 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 which 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 an euphemism for “we don’t really 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 on deadlines: they might be missed, or not, it depends. It may take longer, or shorter, it depends. The routines you need to execute eventually will, but chill a bit because we can’t sign any SLAs here. And this is fine, to some extent and in some specific contexts. Your laptop is missing or rescheduling deadlines all the time, taking longer or shorter to do things depending on workload, for example on the amount 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 to auto-pilot an airliner.
Interesting things happen when you couple non-real-time systems with real-time systems. The success of such hybrid technical mutants 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 GPUs. Or SCADA systems where UIs (non real time) are coupled with distributed PLCs (real time).
As you can see, in this article 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 running at an infinitesimal fraction of speed can be real-time and play ping pong.
Games in general can be considered soft real-time, where execution of deadlines is crucial to ensure game play, 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, responses at the game/user level shall be ensured while at the low level deadlines can be opportunistically lax.
Follow ReOrbit on LinkedIn and Twitter for regular updates!
Contact us at info@reorbit.space
