> Hi!
>
> > 1 is the "its either real time or its not". Thats things like rtlinux. If you
> > say 71uS you get 71uS even if netscape is loading. And for the code modules
> > that are critical to latency you pay in flexibility and API tools.
> >
> > 2 is the "most is good enough" argument. Thats not generally coming from the
> > 'if we miss the building blows up' department of real time computing but from
> > the 'I dont want my MP3 files to jump' school - where perfection isnt the aim.
> >
> > I'm quite interested to see what can be done in #2 without getting to the point
> > it complicates the kernel. But if you are controlling nuclear power stations
> > stick to rtlinux because its much much safer.
>
> *IF* you are controlling nuclear power station, use relays. They are
> less sensitive to radiation, and they do not contain programs. That is
> big advantage, because everybody knows every program contains at least
> one bug.
>
> Pavel
> PS: I can not imagine running nuclear power plant on any os bigger
> than few lines. rtlinux maybe can meat goals in speed limits, but I
> don't believe _any_ system as big as linux is can meat goals with
> stability neccessary for nuclear power plant control...
>
> PPS: I've seen post-crash analysis software running on windows
> 95. Let's hope that nuclear power plant never crashes...
> --
`Realtime` basically means that if you can handle all external events
in a timely manner it's realtime. If the response to an external event
is delayed so that it is no longer current, it is not realtime. If
external events are lost, it's broken -period. Such words as "current"
and "timely" are application-specific. Therefore, if you are measuring
the wear-out of some gears, a program written in interpreted BASIC on a
CP/M machine is "realtime". However, if you are trying to make images
from data acquired at 30 megabytes/second, you need many parallel
DSPs, tightly-coupled, to achieve "realtime".
In nuclear power plants, things (bad or good) happen very slowly.
What you need here is reliability. If the temperature of a thermocouple
(verified by checking multiple thermocouples from multiple data-paths)
gets to some level, you perform some operation (such as a scram).
Such operations, themselves, take a lot of time. So, really, nothing
in a nuclear power plant needs to happen _NOW_. Even the tripping out
of a high voltage, high current CB is delayed to prevent nuisance
trip-outs.
Realtime has turned out to be a "buzzword" which is supposed to mean
"better" than something else. A realtime Operating System is something
that the designer(s) decided was "realtime" with no qualification
required.
In some cases, realtime seems to mean that a user-mode thread can
be executed in the context of an interrupt (callbacks, etc.). In
others, realtime means the scheduler will be notified during an
ISR so that a task, waiting for ISR data, will get the CPU as
soon as possible. All these things are tricks from a programmer's
tool-box which can be used to help prevent external events from
getting old. They, themselves, do not define realtime.
I just read an article from some Industry rag about using Java in
embeded realtime applications. I was about to fire off a letter
to the Publisher explaining that such crap was BS, etc. However,
I started to think about how many things you could make using
Java in its "realtime" application.
o Toasters
o Home thermostats
o Refridgerators
o etc, etc, etc.
...anything that has control functions based upon external data that
changes slowly. -and that's probably 90 percent of the stuff that
is becoming "computerized".
So much for Hype.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/