Software engineers tend to think in deterministic terms. My code tells the machine exactly what to do and that's it. In real world systems there is uncertainty which requires different thinking. A real-time process needs both, a deadline and the concept of errors. A process must be completed within a deadline or there is an error. As the author said, the absolute time (or latency) is irrelevant. Think of a tennis match. you either hit the ball or you lose. There is a deadline and an error. It's not that complicated yet so many people are confused by the concept.
The OS that runs the ECU (engine control, sometimes other such safety systems), sometimes things like brakes, is an rtos because delays can cause death.
But the OS running your driver systems, music player, WiFi, climate control, etc is a non real-time OS, more like android, and that’s reflected in the delays you can sometimes see.
I've seen real time to mean "must finish in x seconds or else fail" which means technically after x seconds you may simply exit the process, and the definition has been fulfilled.
Real-Time. Consistency. High-Availability. Concurrency. Words with too many different meanings are not sufficient for describing softwares. I treat those words as marketing terms.
Originally, the term has really been just opposed to batch processing, in connection with systems like Whirlwind, SAGE, the DEC PDP-1 (as the first commercial real-time system) and is tightly connected to the idea of interactive computing. (Another early real-time system outside of the MIT tech path was MIDSAC, 1953.)
Compare Digital founder Ken Olsen's use of the term in his oral history, "The original computing was based on the way people had done computations before. You'd collect all the data, bring it together, process it and send the answers back. The idea of processing it, real time, took a long time to develop. In the world of commercial processing, it's just in the last few years that batch processing has started to disappear. The replacement for it is now called transactional processing, where if you make a transaction with a bank, it is instantly taken care of." (https://www.computerhistory.org/collections/catalog/10263035...)
There are many applications to this, each coming with their own set of implications. E.g., if you want a smoothly running interactive program on an early PDP computer, you want to have program paths of about equal runtime duration. Which may mean in turn that you would want opt out of no-operation paths as late as possible, by this stabilizing run-time, rather than as early as possible. (E.g., we perform calculations anyway, but apply the result only under a certain condition.) Or, if it is about complex processes, where it may mean that we will fulfil a contract in a guaranteed span of time to facilitate cooperations of any kind (e.g, what Olsen calls transactional processing or matching sampling rates with digital computers as a replacement for analog lab computers). Or it may be bound to a particular domain, where stale data isn't of any use (e.g., compare Whirlwind's origin in a digital flight simulator.) Or it may be just about a system being able to respond to input at all.
The author claims real time has nothing to do with response time. While response time is precisely the point of real time. If a system guarantees the response time of some action is always below a threshold it's real time.
> If a system guarantees the response time of some action is always below a threshold it's real time.
That's pretty much what the author said:
> Real time doesn’t mean instantaneous, or even as fast as possible, it means there’s a clear deadline in the system that the process must complete by a certain amount of time. That deadline need not be milliseconds. It can be weeks. In hard real time systems the system is verified in such a fashion that we can assume it’s impossible for the deadline to be violated. If the deadline is slipped the system is broken.
From what I got, the author's complaint is that most people who talk about "real-time" don't actually define, let alone guarantee such a threshold. Without it, the term becomes a marketing buzzword.
The actual definition is even more strict, implying a system cannot break the deadline because the time cost is completely deterministic and when you start a process you can already know the exact point in time the process finishes. That would rule out using any operations that have a nondeterministic time cost, such as dynamic scheduling or network requests.
I often heard the distinction between "soft" real time and "hard" real time, where "soft" essentially means "can be expected to meet the deadline" and "hard" means the real thing, i.e. "is guaranteed to meet the deadline".
This one knows what's up. In embedded or industrial systems there is "soft" real time which means the deadline can be occasionally missed but the system will still be worthy. Or there may be I think what web or app devs do is mostly at this level. Like the "instant" or "real-time" transfer function offered by your bank. Pretty achievable with commodity hardware and software.
And you have "hard" real time which means the system is worthless if it misses a deadline. Like a stock exchange bombarded by HFT orders, a CNC mill or the airbag controller on a vehicle. Now you will need special stuff like RTOS and synchronous ethernet. It's dead serious, like missing a deadline will destroy the company.
I played with the JACK toolkit on Linux which needs a RT_PREEMPT kernel (hard RT where user applications can cut in queue before kernel stuff) which is quite funny, since people are still making good music with a non-RT windows or mac machine. Most likely you won't need hard RT for consumer facing stuff.
One of the common features of analog is no storage of data, simply passing it on at the speed it comes in.
Once you start buffering or storing the data that's when artificial delays can be introduced that can be so much different than analog that you perceptibly lose an element of continuity.
Electronically, to retard analog signals very much there were integrated circuits like delay lines, where the incoming signal was passed from silicon cell to cell an excessive number of times simply to achieve a desired latency from the output pins.
This is almost the equivalent of a FIFO buffer so often used in handling digital signals.
Yeah, I would say "cannot be preempted", so the author is right it can be understood to mean different things. I've never heard of this "has a deadline that can't be broken definition" before.
It is pretty much the definition for real-time for anyone who has worked on embedded, safety, and critical systems. Preemption is about priority, which is a property of parts of the real-time system. A real-time system with only one kind of thing it's doing doesn't have to deal with priority (too much), but in communication systems (like between aircraft and air traffic control) there may be messages which will always be processed within some unit of time, and others which can be deferred or even discarded if they are preempted by a higher priority message. The whole system is still real-time. Usually with a fixed processing cycle. For a radio, maybe every 1/100th of a second it will receive, process, and transmit, repeat. Priorities determine what gets transmitted and processed in any given cycle based on various inputs from the aircraft, the aircraft operator, or other radios in the network.
That 1/100th of a second cycle time and the guarantees associated with it are what make it a real-time system (a hard real-time system, in this example).
