OT: safer nuclear reactors [LWN.net]

OT: safer nuclear reactors

Posted Oct 15, 2004 20:07 UTC (Fri) by Baylink (guest, #755)
In reply to: OT: safer nuclear reactors by nix
Parent article: Approaches to realtime Linux

I believe the substance in question is "depleted uranium", as used in weapons systems, among other things.

A better analogy, IMHO, for when hard realtime response is necessary, would be industrial robotics: if a 400lb swingarm is about to crush a human, guaranteed millisecond response is in fact essential.

But Linus and I had an exchange about this, a few years back, carboned to this very venue, and he convinced me that if what you need is that hard realtime, then you should probably not be doing anything else with that computer.

http://lwn.net/2000/0713/backpage.php3

to post comments

OT: safer nuclear reactors

Posted Oct 21, 2004 14:15 UTC (Thu) by alext (guest, #7589) [Link] (1 responses)

Generally true with respect to ordinary OS tasks. Often though you want to respond to specific events within a fixed time limit or always do X at interval Y. Neither things using all the CPU resource, leaving gaps to fill. What you do the rest of the time is low priority things that don't matter them not happening bang on interval Yn to within nanoseconds.

That is my experience from automotive engine controllers. On those we do lots of low priority things. The issue that comes in to play is testing and validation. If you are running other tasks on a controller with safety critical tasks generally you want to test everything to the higher standard if you are mixing on a shared host.

Related to running something like Linux as a low priority task under a hard real time system gives the argued (I have my doubts) ability to sandbox the none safety critical tasks so that they can't do things to interfere with the safety critical portion.

OT: safer nuclear reactors

Posted Oct 21, 2004 17:07 UTC (Thu) by Baylink (guest, #755) [Link]

This is, as always, a tradeoff.

Response latency can usefull be characterized as "M% of the time, the system will successfully respond within N ms." The more important it is to you, the closer to 100 M must be.

But the underlying point is that for values of M less than 100.0, it's often possible to combine soft-real-time techniques with throw-hardware-at-it, and get a useful result. And Linus' assertion, with which I agree now, is that if you really need 100.0%, because people may be hurt or killed, or the value of things which may be destroyed is sufficiently high, that at *best* you should indeed be running Linux as a task under a small, tight, HRT kernel.

LinuxRT and RTAI may be good enough; they may not.