Re: [offtopic] Re: 2.2.2: 2 thumbs up from lm

Richard B. Johnson (
Thu, 25 Feb 1999 17:19:54 -0500 (EST)

On Thu, 25 Feb 1999, Neil Conway wrote:

> Richard B. Johnson wrote:
> > 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.
> You seem to think "realtime" computing has a wishy-washy definition.
> Not so.

I defined exactly what a realtime operating system does. It is not
wishy-washy at all. But you snipped that off and reply only with
the current buzzword context. I could edit your response and make
it look absurd, also.

> One of the key points of a realtime system is that any latencies be
> bounded. That's something you'd have one hell of job claiming for a lot
> of OS/app combinations. Don't mistake "usually adequately fast" for
> "realtime".

Now, where does it say anything about "bounded latencies". By what
authority? Since I defined realtime, I would like to know how
an additional definition got appended to destroy the concept.

Again, an operating system is realtime, if it can respond to
external events while they are still current.

To carry this to its logical conclusion, it becomes obvious
that buffering or queuing does not help because once the second
event gets into a buffer, or onto a queue, the first is no longer

If you want an OS that chops every task's CPU usage into, say,
microsecond intervals, to obtain microsecond latency, you are not
defining "realtime", you are defining an entirely different concept
which is called controlled latency.

Controlled latency is used when you need to create a filtered function
and need strictly defined sampling intervals so that the resulting filter
characteristics are deterministic. This is not generally done in a
multi-user environment, in particular where variable length data are being
read or written from file systems and networks. This is because
interrupt activity, DMA activity, and such adds randomness to
the sampling interval.

Note that interrupt activity makes the CPU "seem" slower to the
application because the CPU keeps getting taken away. DMA Activity also
make the CPU "seem" slower because the data bus keeps getting taken away.
The result is that application level activities will tend to bunch up
around intervals of interrupt and DMA activity. In the limit, all
tasks become computable simultaneously, destroying your precision

I am aware that there are many companies that make a living providing
"realtime operating systems". I am also aware that few actually know
what it means. Again, it has become a buzzword to sell something that
such a company thinks is "better". Once you actually try to write
an application that works in such an environment, you get to understand
that "better" doesn't guarantee functionality.

Dick Johnson
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
Please read the FAQ at