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.
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.