4 ms·

I blame all the misguided folks who try and add "soft real time" to time sharing systems like Unix/Linux/etc. Anyone who does that has a profound misunderstand

I blame all the misguided folks who try and add "soft real time" to time sharing systems like Unix/Linux/etc. Anyone who does that has a profound misunderstanding of what real time is, it most definitely is not a time sharing system. If you want a time sharing system and real time, that problem has been solved, in a really elegant way. Victor Yodaiken did it years ago, he made a small real time kernel and he ran all of Linux as the idle process in the real time kernel. When Linux thought it was disabling interrupts it wasn't, only the real time kernel could do that. He had a demo where he was running xperf (or some fairly compute intensive X thing) while running tar cf - / | rsh someotherhost 'cat > /dev/null' while the real time kernel was gathering events. He never missed a deadline or dropped an event. Sweetest design I've ever seen, have your cake and eat it too.

AnthonyMouse 11y ago
> I blame all the misguided folks who try and add "soft real time" to time sharing systems like Unix/Linux/etc. Anyone who does that has a profound misunderstanding of what real time is, it most definitely is not a time sharing system. Part of the problem is that there are realtime systems where, if you don't meet the deadline, the plane will fall out of the sky. Then there are realtime systems like VoIP where, if you don't meet the deadline, the call will cut out. And there is a desire to get "almost realtime" for things like VoIP on general purpose time sharing systems, where you want to deprioritize less latency sensitive tasks in order to hit the deadline if you can, but nobody dies if you don't. The trouble with using "real" realtime in those systems is that the system may not have enough capacity in theory even when it does in practice. In other words, if you have three concurrent realtime processes that could each in theory use up to 50% of the available resources at a time, but in practice almost never use more than 10% each, then for less critical systems you may be willing to bank on "almost never" not happening often enough to matter.
- qznc 11y ago
  Imho "soft" and "hard" real time distinguish pretty well between "must meet deadline" and "should meet deadline". The only problem I see is that they sound so similar, although the development process is radically different between the two.
lukeh 11y ago
Is this similar to what IntervalZero's RTX64 does on Windows?
- luckydude 11y ago
  No idea, I poked at their website for a minute (sorry, been clearing trees off our road all day, super tired) and didn't find a writeup of what they have. If you can find one I'll read it and see if I can figure it out. There is a wikipedia page for Victor's stuff: https://en.wikipedia.org/wiki/RTLinux https://en.wikipedia.org/wiki/RTLinux

AnthonyMouse 11y ago

> I blame all the misguided folks who try and add "soft real time" to time sharing systems like Unix/Linux/etc. Anyone who does that has a profound misunderstanding of what real time is, it most definitely is not a time sharing system. Part of the problem is that there are realtime systems where, if you don't meet the deadline, the plane will fall out of the sky. Then there are realtime systems like VoIP where, if you don't meet the deadline, the call will cut out. And there is a desire to get "almost realtime" for things like VoIP on general purpose time sharing systems, where you want to deprioritize less latency sensitive tasks in order to hit the deadline if you can, but nobody dies if you don't. The trouble with using "real" realtime in those systems is that the system may not have enough capacity in theory even when it does in practice. In other words, if you have three concurrent realtime processes that could each in theory use up to 50% of the available resources at a time, but in practice almost never use more than 10% each, then for less critical systems you may be willing to bank on "almost never" not happening often enough to matter.

qznc 11y ago
Imho "soft" and "hard" real time distinguish pretty well between "must meet deadline" and "should meet deadline". The only problem I see is that they sound so similar, although the development process is radically different between the two.

lukeh 11y ago

Is this similar to what IntervalZero's RTX64 does on Windows?

luckydude 11y ago
No idea, I poked at their website for a minute (sorry, been clearing trees off our road all day, super tired) and didn't find a writeup of what they have. If you can find one I'll read it and see if I can figure it out. There is a wikipedia page for Victor's stuff: https://en.wikipedia.org/wiki/RTLinux https://en.wikipedia.org/wiki/RTLinux