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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST