Mike Cravens
Paul Murray wrote:
**** Please Note ****
The following (long) note is about worst-case interrupt response on
"general-purpose" computer systems. Perhaps this list is not the place
for it. If this doesn't interest you a *lot*, you might want to delete
this message, and go on to something else...
********************On Thu, Mar 04, 1999 at 05:27:07PM +0100, Thomas Fruehbeck wrote:
>
> Hi Daniel,
>
> You wrote:
>
> > Peter Wurmsdobler wrote:
> > >
> > > Hi,
> > >
> > >
> > > 1. Would an ordinary linux kernel be sufficient or do I have
> > > to use rt-linux in order to guarantee that this periodic task
> > > can not be interrupted by any other interrupt?
> >
> > It depends on the sampling frecuency, but in a general purpose operating
> > systems the interrupts can be bloqued for 10's of milliseconds, so if
> > you need more than 100 Hz of Sampling freq. you need RT-Linux.
> >
>
> Where did You take the information, that plain Linux may block interrupts
> for 10's of milliseconds?
> To me this seems queer. I can not imagine my Linux box (compile, install, X, Xvnc server)
> would reach it's phantastic performance, if any driver would think of blocking
> interrupts for even 1 millisec.
>An OS and its drivers need critical regions to protect system-wide
data structures and lists. A critical region ensures that only one
thread can modify the resource that the critical region protects.
A classic example is the use of a critical region to protect the ready
list from ugly interactions between the scheduler and device drivers:
driver ISRs(Interrupt Service Routine) frequently want to wake-up client
processes, send signals, and other stuff which modifies the ready list.
If one or more drivers changed the ready list while the scheduler was also
changing it, things begin to look non-deterministic, users get irate,
and bad things(tm) happen. So, schedulers and drivers modify the ready
list within a critical region; the scheduler gets protection from ISRs,
and ISRs get protection from higher priority ISRs.A common way for OS code (system and drivers) to enforce a critical
region is to
1.) disable interrupts,
2.) fool with the resource,
3.) enable interrupts.If the OS has massive tables to update, or has to insert a process in
a long priority queue, interrupts could be disabled for a long time (in
real-time terms - eg; 10's of ms). If you are not programming a real-time
system, this is not a problem as long as it doesn't happen very often.The experience of poor souls who have tried to use UNIX or NT as real-time
systems confirms this. Most of the time, interrupt response ain't too
bad (not remotely close to rt-linux, but not too bad). The worst-case
interrupt response is a different matter entirely. It is the worst-case
which Daniel describes. And it is very real.In olden days, if you had a complex control or acquisition task which can
not endure the worst-case, you wrote or bought a "real-time" executive
(which made no pretense of pandering to the masses), wrote the application
for a dedicated machine, and perhaps used this real-time system as a
front-end to your "general-purpose" computer.rt-linux succeeds at changing this model by sandwiching a real-time
interrupt handling and real-time task environment under linux.
This real-time environment virtualizes the linux interrupt environment.
When linux needs a long critical region, the processor does not really
have its interrupts disabled. Interrupts for linux are just postponed
until linux exits its critical region and re-enables its (virtual)
interrupts. The real interrupt environment continues to run, unaffected
by the linux critical region. This real-time environment shows average
and worst-case interrupt latencies which compete *very* favorably with
any "real-time" OS.Folks have tried to put real-time systems under NT, but the resulting
systems normally provide OK interrupt response latency, but have
unacceptable worst-case behavior for many (unhappy) users. Perhaps when
Micro$oft makes NT open-source, the Linux community can fix it ;).
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
-- Alcatel USA Internet: [EMAIL PROTECTED] 1000 Coit Road Plano, Texas 75075 **** The opinions expressed are not those of Alcatel USA ****
