Real-Time OS

[Nick Bannon]

On Sun, May 21, 2000 at 01:31:15PM +0800, Christian wrote:
> Isn't it also the resolution/granularity of the time measurements?  For

Practically speaking, the faster the better, but there's not really a
lower (slowest) limit - it depends on your application. A CD burner
with some buffer may only need to be fed once every second or two -
it's not really that much of an ask, but it still has to be met in
real time.

Mind you, it's that looseness that makes people try to claim that
Windows CE is suitable for embedded or real-time systems, despite its
glacial context switches. (In a Doctor Dobb's Journal a while back I
saw someone actually put a number to that - I think it was on the
order of 100ms)

It's about determinism, preferably low jitter, and making sure that the
worst case is acceptable rather than merely rare.

> example, you can use POSIX real-time scheduling under Linux but the
> granularity is up to +10ms out because of the scheduler.  For many
> real-time applications 10ms is far too coarse.

Oh, certainly, and by taking the step to a system like QNX, perhaps,
you can reduce that to microseconds. Interestingly enough, those
sorts of numbers can be easy to achieve on tiny little microcontroller
systems - they could be hundreds of times slower at processing than a
desktop, but if you can wire up an interrupt line to the thing you're
monitoring, or if you can afford to turn off interrupts and poll like
mad, it's easy to get fast and deterministic response times.

> > On some systems (like Irix) you can say that some particular process is
> > a "real-time" process, which means that if it wants to hold onto the
[...]
> Linux does this too.

I knew it did as an extension - Hard Hat Linux or RTLinux, for
example, but I wasn't aware you could do that on a normal system.

Nick.

-- 
  Nick Bannon  | "I made this letter longer than usual because
nick at it.net.au | I lack the time to make it shorter." - Pascal