Re: Ada OS Kernel features

["Brian Catlin" <briancatlin@mindspring.com>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:VLvl7.5404$4z.21201@www.newsranger.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).

This is the point at which Rate Monotonic Analysis (RMA) enters the picture.
The behavior of real time (and isochronous) tasks need to be well understood in
order to schedule them effectively.  Usually, RMA is the provence of real-time
systems, but to effectively support a _few_ isochronous and real-time tasks in a
general purpose operating system, we should build some tools (performance
counters and such) for measuring the behavior of these tasks to help the author
better optimize the code (and overall system performance).

> 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.

Well, I wouldn't hold Mach up as the end-all or be-all of operating system
kernels; its performance is nothing to brag about.  It certainly has many
interesting concepts, but its overhead is too high for my taste (I haven't
looked at it in several years, so it may have been cleaned up; I'll have to go
check it out again).  As I mentioned in a previous post, by implementing drivers
as essentially applications in their own processes, the system will incur a huge
amount of overhead invalidating the translation lookaside buffer and the
accompanying multiple mode transitions for process context switches.

 -Brian