Tue, 21 Mar 2000 [EMAIL PROTECTED] wrote:
> > Sat, 18 Mar 2000 Alain Rollé wrote:
> > > To end with, one more question :
> > > In the RTL manifesto is stated that :
> > > "You can have deterministic worst case behaviour time on Solaris RT, but the
> > > worst case is really worse than you might be willing to tolerate"
> > > Can anyone give me an indication of the worst case time between the moment a
> > > hardware interrupt is detected by the processor and the moment an interrupt
> > > handler starts to execute with Solaris RT. I can't seem to find these figures
> > > on the sun site.
> >
> > Well, I had a look, and I can't find anything but "...in a future version of
> > this document." Where are the figures? I actually thought Solaris had hard RT,
> > thanks to their brutal rape of their kernel (ie making it fully preemptive),
> > but if it's hard to find the figures (if they exist), one starts to wonder if
> > they're hiding something...
>
> I saw them quote 2ms on a dual with some odd configuration,
Quite acceptable for normal multimedia, but it seems to be a higher system
requirement while still getting worse peformance than Linux + lowlatency...
> > Anyway, AFAIK, their solution is basically meant for real time multimedia and
> > that kind of stuff, which means that worst case latencies in the ms range are
> > acceptable. We're not dealing with latencies in the same order of magnitude as
> > RTLinux, QNX and other dedicated RT solutions. You just can't get that
> > throughout the system without compromising non-RT performance.
> >
> > With Linux + lowlatency (hard RT for user space), we are pretty certain that we
> > can guarantee sub ms latencies for SCHED_FIFO threads on correctly configured
> > P133+ systems, and we're still dealing with a non-preemptive kernel. If
>
> I'd love to see a solid timing study showing that.
There is some test tools + test data from various systems at
http://www.gardena.net/benno/linux/audio/
> Can you do
> ping -f someone &
I've only tried localhost personally, but I'll try it on this machine (Dell
400 MHz P-II) as soon as I get around to install a sound card and/or apply the
async signal patch for the RTC. (El cheapo NIC - probably lots of IRQs and data
copying.) I have an old P200 with a different NCI here to try this on as well.
> while true; do tar cf /dev/null /dev/hda_x ; done; &
Tried reading, writing and copying huge files, grepping the entire disk and
updatedb without problems.
> while true; do make -j 4 bzImage ; done; &
Tested. No problems. User space CPU load is basically a non-issue - it's some
loops in kernel space (scanning lists, copying memory,...) that cause the
remaining scheduling latencies. (And Linus was, to say the least, not very
happy with Ingo's proposal to make those areas fully preemptible.)
> and still get sub ms latencies?
> That would be cool.
I have run the latencytest (the audio output part; includes disk, procfs, CPU
and X stress) on a Celeron 333 and a P-II 233 - standard Red Hat Linux +
lowlatency kernels - with;
* 2.18 ms buffering
* 3 fragments
* 80% CPU load in the RT thread
(That is, more than .42 ms latency total for 3 subsequent fragments, and you
get a drop-out.)
I've also tried ping -f localhost and various other stress tests without being
able to cause a single drop-out. I'm not sure if anyone has tried stressing
NICs (lots of interrupts) already, but I'd be a bit surprized if not.
Regards,
//David
P r o f e s s i o n a l L i n u x A u d i o
· ··-------------------------------------------------·· ·
MuCoS - http://www.linuxdj.com/mucos
Audiality - http://www.angelfire.com/or/audiality
David Olofson - [EMAIL PROTECTED]
-- [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/
