The most realistic definition of a real-time system that I have heard is: It is a RT system when your results are ready when they need to.

That's it. That's what an RT system is. I don't care if your latency is 1us, 1ms, 1s or 1h. If you can't miss the deadline then your system is a real-time one.

Low-latency then depend on how your strategy works and your particular needs. It's useless to have sub ms timing of stock market data if your results take seconds to calculate.

Of course, your strategy that takes 1s might be more lucrative than one that takes 10ms to calculate. Then it's up to you and your algos.

That’s correct: a real-time system can be slower, if that’s what it takes to be deterministic. And usually that is one of the things it takes.

I have never understood why people might think it ought to be faster.

It is another classic confusion between a definition in technical jargon (maybe even a formal definition) and the vernacular. Real-time for most people means "instantaneous," and definitions of latency are not considered. So it is a shorthand for "low-latency" without a rooted understanding latency at all.

I don't understand all this confusion about what RT means, this is the definition of a RT system. If you can't complete the computation within the given deadline whatever partial result is discarded and the computation starts from scratch.

Decoding video and interactive rendering is a great example of an RT system. If you can't construct a frame within (usually) 16 ms you skip it and start with the next one.

There is a difference between hard real time and soft real time. Hard real time systems mean that missing a single deadline may be a crash, whereas a soft real time system, missing a deadline just causes a degradation. Video is definitely soft real time.

Hard and soft real time depend entirely on the context. An example of hard real time is flight control. The whole sensor - actuator - decision process must happen within the given threshold.

But decoding video in practice isn't usually realtime because you still have to do it when you don't have kernel support and are at the whim of your kernel's scheduler which is basically always.

It's a good example of a problem where a realtime system would be useful but it's not a good example of a real-life realtime application (usually).

You can write low latency Java but by the time you do, the C++ will have taken a similar amount of time.

The time to market argument is really stupid imo.