Stop Using “Real Time” Wrong • Hacker News Board

Re: Stop Using “Real Time” Wrong

#21

Post by gaudat » Mon, Jul 25, 2022, 2:05 AM UTC

_0ffh wrote: post #8

xg15 wrote: post #3

Earlier quoted context omitted.

> 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 ver…

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.

Re: Stop Using “Real Time” Wrong

#22

Post by fuzzfactor » Mon, Jul 25, 2022, 2:53 AM UTC

rowanG077 wrote: post #2

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.

For me real-time means analog-like.

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.

Re: Stop Using “Real Time” Wrong

#23

Post by cuteboy19 » Mon, Jul 25, 2022, 11:14 AM UTC

gaudat wrote: post #21

_0ffh wrote: post #8

Earlier quoted context omitted.

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…

Realtime payments just means the opposite of batch. It may even take days for the payment to go through