Messages in this thread | | | From | Benno Senoner <> | Subject | Re: a joint letter on low latency and Linux | Date | Sun, 2 Jul 2000 10:53:29 +0200 |
| |
Richard Gooch wrote: >Larry McVoy writes:
>> >> "All we need is guaranteed scheduling response". But it's not real >> time. >> >> Those two statements are 100% at odds with each other. > >Not if you read it this way: "we want feature XYZ, but we won't call >it RT, because then people will tell us to use RTLinux, and we don't >want to do that.". > >I think people advocating the scheduling/preemption hacks should go >and run some exhaustive tests to find out how bad the latency can be >with said patch, and then identify where the remaining latencies are >coming from. Then fix the worst offender and run the tests again. > >My guess is you'll be digging yourself in deeper and deeper, >sprinkling random hacks in random places, as Linus put it. > > Regards, > > Richard....
I can say only that I tried my best to generate higher than 2msec latency spikes on a my old P133, but I failed.
I have no mathematical proof that the lowlatency patch provides "hard realtime", but but empirical testing under extreme conditions show us that works well for doing realtime multimedia. well = a P133 with 64MB RAM where the following tasks were started ALL simultaneously:
- cp -r /dev/cdrom1 /tmp and cp -r /dev/cdrom2 /tmp (TWO IDE CDROMS (DMA tuned or latencies will suck) : that means copying the entire contents of two CDs simultaneously to the disk
- cp largefile1 largefile2 ( 500MB from disk to the same disk)
- a few instances of kfract
- top -d 0.01 (top which updates the process list 100 times per sec (at least it tries so))
x11perf -scroll500 -shmput500
- a small C program I wrote which forks about 200 processes and then each one wastes CPU in a busywaiting loop
During the tests the mousepointer is almost frozen (moves VERY jerky, but that is because the X server is run as a regular process)
BUT THE LATENCY GRAPHS DO NOT SHOW UP A SPIKE OVER 1.5msecs or so.
So your "My guess is you'll be digging yourself in deeper and deeper" statement makes no sense to me.
The load I created is certainly bigger than the average load of a desktop system, thus even if the lowlatency patch can not called "hard realtime", it is SUITABLE for realtime multimedia.
(Immagine that if the P133 can deliver these latencies, what a 1GHz PIII can do ...)
tons of songs were created using a windows or a Mac box (both FAR away from an RTOS) so I don't see why Linux should be unsuitable for this task.
the risk that we could loose 1msec of audio during the next 50 days because lowlatency is not hardrealtime is not worth to switch to RTLinux.
... just like saying better not take the plane, it might crash such is life :-)
(we live in a statistical world)
Benno.
- 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/
| |