User: Password:
Subscribe / Log in / New account

OT: safer nuclear reactors

OT: safer nuclear reactors

Posted Oct 14, 2004 9:58 UTC (Thu) by nix (subscriber, #2304)
In reply to: OT: safer nuclear reactors by jvotaw
Parent article: Approaches to realtime Linux

`non-radioactive Uranium'? An interesting substance: a shame it doesn't exist.

(Log in to post comments)

OT: safer nuclear reactors

Posted Oct 14, 2004 13:34 UTC (Thu) by jvotaw (subscriber, #3678) [Link]

I stand corrected. Even pure U-238 is (minimally) radioactive, it seems.

The larger point remains: this is a substance that is widely considered safe enough to be used in ceramic glazing, sailboat keels, race cars, oil drills, etc. (Although, admittedly, not safe enough that you'd want to turn it in to a powder and disperse it into the air or water.)

Thanks, Wikipedia.


OT: safer nuclear reactors

Posted Oct 15, 2004 20:07 UTC (Fri) by Baylink (guest, #755) [Link]

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.

OT: safer nuclear reactors

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

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.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds