Messages in this thread | | | Date | Thu, 25 Feb 1999 17:19:54 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: [offtopic] Re: 2.2.2: 2 thumbs up from lm |
| |
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 current.
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 time-slicing.
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.
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/
| |