Subject: Re: [linux-audio-dev] Re: new preemptive kernel-patch from Montavista available
From: yodaiken_AT_fsmlabs.com
Date: Fri Nov 24 2000 - 04:48:47 EET
On Thu, Nov 23, 2000 at 11:35:39PM +0100, Benno Senoner wrote:
> I'm by no means an expert, but judging prurely based on testresults,
> the preemption-based approach (even Andrew patches which are not that intrusive
> as Ingo ones) seems to be suitable to cover the need most realtime multimedia
> apps. ( 2-3msec)
I like Andrew's patches, which are not particularly intrusive, but are well
chosen. I don't like the IRIX/REAL-IX method because it seems to me to sacrifice
too much in order to gain too little.
> Of course I'm curious to see what kind of performance RTLinux signal handlers
> would deliver.
>
> But for that we should measure performance under the same conditions as
> when using latencytest (RTC or audio IRQ).
>
> So what would need to get rewritten is latencytest
> (http://www.gardena.net/benno/linux/audio)
> in order to support RTLinux signal handlers, but that code is a piece of crap
> and not worth to touch anymore.
>
> My goal was to rewrite latencytest from scratch using latency-graph to record
> and display the data, plus perhaps integrating "pluggable" stresstest routines.
> (eg where one can choose to include his script / executable to perform
> additional stresstest)
>
> But unfortunately for now I'm hopelessly ovebooked .. :-(
>
> On the other hand if you look at the latencytest outputs almost all spikes are
> while waiting in the write() call (writing to soundcard) so basically the
> non-determinism happens when we are sleeping.
>
> I'm not familiar with the RTLinux userspace signals model, but in the case
> of latencytest you would need a method to wake up the thread after
> one fragment has been processed.
> Would this involve the standard write() call (with /dev/dsp as a device) too ?
> If yes, this point aren't we suffering from userspace scheduling latencies too?
> I mean, if the kernel code is just doing some lengthly operation
> (like traversing zillions of inodes), can we preempt that piece of code, even
> with IRQs disabled ?
> correct me please if I'm wrong.
I have to look at it, but probably we would want to put in a simplified soundcard driver
and do RT writes which would not need to wait for Linux.
> As you hard-RT guys know, even on multimedia we are interested in
> "worst case" (*) latencies.
> (*) worst case = we can do not encounter a value higher than this for
> several days. (as opposed to "never encounter ... " in RTLinux)
RT is a benchmark nightmare.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
This archive was generated by hypermail 2b28 : Fri Nov 24 2000 - 05:43:01 EET