To put a slightly different spin on qwertox's reply: What matters is that the OS can guarantee how long it will take for, say, a high-priority task to become active after it is activated. It's not a matter of the absolute numbers; it's the ability to make a real guarantee. Of course, the bigger the number, the harder it is to make a guarantee at all, because there are more things going on, and are you sure you got all of them? But with a real time OS, there are far fewer things that happen in such a case, and so it's easier to calculate and to prove that yes, it really will respond within X cycles.

There's a lot of subjectivity in these definitions. But an overnight batch job run once a week would usually not be considered a realtime task. The duration of the job and the time resolution of its deadline is pretty large compared to the CPU scheduler timeslices used by general-purpose operating systems, and you probably don't need any special hardware support. You just need to provision enough CPU time overall, and not allow the job to be starved by higher-priority tasks consuming all the available CPU time.

A task would usually be considered realtime to some degree if it cannot automatically get its work done on time even when competing with a background-priority long-running job—for example, if your deadlines are operating on similar or smaller timescales to the operating system's CPU scheduler. Then you need to start taking extra measures to ensure adequate responsiveness, not just adequate throughput.

But there's also the aspect of consequences of missing a deadline. Most realtime tasks are concerned with millisecond or shorter timescales, but a job that must be performed once every 108 minutes to prevent the end of the world would also be reasonably considered a realtime task.

Yeah, it would be nice to have a real-life example with a relatively lengthy latency. Perhaps with delivering an organ for a transplant or something.

At least wrt soft realtime scheduling for audio, I think users/programmers tend to get severely tripped up because the latencies are simply too small for them to make a clear mental model of the underlying system. That, along with their ineluctable desire for their code to "go faster" drives them to request features or design algorithms which would have to travel "back to the future" in order to work at all.

So it would be nice to decouple "ultra-low latency" from "realtime" to make it clear that, say, you can't put the heart on ice after the helicopter already lifted off to fly it to the hospital.

If you're actually paying attention to guaranteed worst-case runtimes to make sure that something completes within a week, then it would be fair to call that a real-time system and real-time techniques would be relevant. If you're running it on a backend with no firm worst-case guarantees and trusting that it won't take too much longer than the average time then that's not a real-time system.

If you're expecting to always get the data in 5 cycles but you sporadically get in 250 cycles, you're no longer on a realtime system. The latency per se doesn't matter, as long as it is what you expect it to be.

Its application-specific:

i.e. A spacecraft that requires a thruster to be fired with accuracy of a few hundred milliseconds in two years time has mission/safety critical timing requirements. Therefore this is hard-real-time

Alternatively, a payroll that has to run at the end of every month will not cause people to miss payments if that deadline is missed by any relatively large amount of time (minutes/hours). The timing requirements are not mission critical at this point. They could be considered soft-realtime tho as there is still an upper bound to desired behaviour.