Re: Ada OS Kernel features

[Ted Dennison<dennison@telepath.com>]

In article <9n5n33$ke5$1@nntp9.atl.mindspring.net>, Brian Catlin says...
>
>An isochronously scheduled task means that the task will get a fixed amount of
>CPU time over time (think of it as getting a fixed percentage of the CPU over
>time).  Supporting isochronous tasks is a requirement if you want to be able to
>handle streaming multimedia, such as audio or video.  A simple way to implement

Ahhh. That explains it. The multimedia folks do seem to like that term. They
used it in pretty much the same sense in the FireWire spec (reserving a % of the
bus bandwidth). 

However, I don't see anything in there that really speaks about jitter. Perhaps
jitter reduction (making sure the task starts regularly at the exact same time
every cycle) is just an implementation detail they don't like to talk about
explicitly? 

The only easy way I've found to prevent jitter is to schedule a task to be the
first one that runs after the clock tick. Clearly the amount of tasks one can
use this solution on is limited by the product of your clock period and the task
frequency (eg: 240Hz clock w/ 60Hz threads gives you at most 4 possible
jitter-free tasks).

However, I heartily agree that the scheduling algorithm would need to be
different for RT and non-RT tasks.

>Yes, it makes them more difficult to debug, but placing the drivers in the
>kernel has several benefits:
>1. Processing an I/O request requires access to privileged system routines and
..
>2. Putting drivers in user-mode means increasing the number of transitions
..
>3. A driver will need access to the requesting process' address space, but if
..

Interesting. But I'm pretty sure that Mach puts *all* device drivers into user
space, as well as large parts of the kernel.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com