In <00070211154701.00802@linuxhost.localdomain> Benno Senoner (sbenno@gardena.net) wrote:
> 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.
It's benchmark. Benchmark is great way to spot the problem but it's not very
usefull to prove that you have solution.
> 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.
If it's good for you then use it ! What's the problem here ? If you want it
to be included in kernel... It's COMPLETELY other story.
> (Immagine that if the P133 can deliver these latencies, what a 1GHz PIII can
> do ...)
I dunno. If latencies were due to some PCI bus interation then you'll get
the same 1.5ms or EVEN WORSE (PCI bus on 1GHz PIII can be slower in some
[rare] situations). That's the point: you find that patch works great to
you. You STILL have any proof that it'll do the same for millions of other
boxes out there.
> 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)
You - may be. Linus - not :-) That's why Linus works (unlike some other OSes).
-
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:11 EST