Messages in this thread | | | Date | Mon, 1 Mar 1999 13:19:22 +1100 | From | Richard Gooch <> | Subject | Re: real-time support in Linux (again) |
| |
yodaiken@chelm.cs.nmt.edu writes: > > > > 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.
OK. BTW: I don't see where/what the 3 orders of magnitude cost difference comes from. I just see 2 orders of magnitude.
> The time from entry of handler seems meaningless.
Not to marketdroids.
> > Also, the 2 ms case Sun quotes: what kind of hardware is that? > > I saw that for a dual ultrasparc.
<smirk>
Regards,
Richard....
- 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/
| |