The future of realtime Linux in doubt

And in this case, that's exactly what happened - the guy used "real time" in a manner I didn't understand, and when I queried it and said "I think you mean "online" ", his reaction was "well, they are the same thing now, who cares".

Sorry, I do care very much because if we define away the meaning of words, we then have no way of expressing that concept, and the meaning of "real time" is life and death! As others have said, real-time is about deadlines, and when you're dealing with industrial plant, that could well be a DEAD line.

And if you're stupid enough to change one word into another, like here using "real time" when there's a perfectly good word "online", then I'm sorry but you damn well shouldn't be a journalist! The grief people have caused me (when I did PC support) because they refused to learn the difference between "memory" and "disk space", or "PC" and "terminal", and probably various other terms as well. If I have to teach them, then fine. If they refuse to learn, well, I'm sorry if I trashed your system by mistake because you didn't want to express yourself clearly ...

Cheers,
Wol

As to your bigger hammer, if my guess as to its intended use is correct, then you are going to have to get in line. And it is a very long line. :-)

And I completely agree that real time is a property of the entire system and its environment, not just of the software. "Hard real time" software doesn't help much unless the rest of the system and the environment are also amenable to hard real time.

Although I agree that math can be used approximate some important behaviors of the real world, it is quite easy to take things too far. In particular, any attempt to define a real-world hammer out of existence is unlikely to end well. ;-)

As an exercise, I'll let you propose definitions for: comic realtime, poetic realtime, theatral realtime, etc. ;-))

Much better would be to see it might miss the deadline and for system to take avoiding action, so it meets a goal perhaps with degraded performance.

A processor might normally run down-clocked in a power saving freq. state. if a process which required 1ms CPU time every 100ms according to some worst case analysis, was in 'danger' then scheduler engaging a turbo mode 10ms before expiry and running that task as priority, provides the CPU time without reducing other tasks resources.

Presumably it's possible to have hardware normally use interrupts but fall back to polling of hardware registers, for instance.

Nice try, but you missed the mark.

The problem is that as you push towards the limits of the system's capabilities, you must be increasingly careful about when and how you apply abstraction. Out at the limits, little things that might otherwise be confined to a given piece of the system start making themselves felt globally. Therefore, out at the limits, premature abstraction is the root of all evil.

In short, at the extremes, you don't have the luxury of defining the software independently of the rest of the system.

One saving grace is that today's hardware can trivially meet requirements that were out at the limits a few decades ago. So the limits have moved out considerably over that time. However, the global awareness required at the limits remains unchanged.

The problem with any big and complex system is that you cannot reason and make proofs about it. One example is memory management: since it's shared across the whole system you can never predict how long it will take since it depends on too many other things.

So, again as an example, would you qualify as a "bug" an involvement (direct OR indirect) of the memory manager in your real-time thread(s)?

Now more general questions about the -rt branch (pardon my ignorance): is it possible to use -rt to implement something which is both "hard" real-time and non trivial and that does involve neither any memory management nor any other unpredictable part of the kernel? Or are people using the -rt branch just because it gives typically lower latencies?