lkml.org 
[lkml]   [1999]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: real-time support in Linux (again)
Date
> 
> yodaiken@chelm.cs.nmt.edu writes:
> > > what's the difference between using rtlinux for real-time and linux for
> > > time-sharing, and Sun's approach with Solaris where the scheduler
> > > algorithms are contained in something akin to loadable kernel modules?
> >
> > Sun advertises 2millisecond worst case response time on a dual
> > processor that is only running their "rt" on one processor. RTlinux
> > gives 40microsecond response time on a single 486. So the difference
> > is about 2 orders of magnitude in performance and plus 3 more in
> > cost.
>
> >From when is that response time measured? From the time the CPU enters
> the interrupt handler, or from the time the interrupt hits the CPU?

I'm sorry, but I mistated things. The 40microseconds is worst case jitter
on a periodic task that measures jitter by reading the timer and looking
at the difference between expected and actual time. On a P5 or better
we use the rdtsc and get a lower number -- low 30s. Interrupt latency is
significantly better then that, because some of this jitter is caused by
the timer itself. I haven't measured this recently, but according to
some people who have on the RTL list, the times are somewhere under 10us
on a decent PII. All of this is time from asserting the interrupt to
handler response. The time from entry of handler seems meaningless.


>
> Also, the 2 ms case Sun quotes: what kind of hardware is that?

I saw that for a dual ultrasparc.
>


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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.039 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site