Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles

Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles

[Benno Senoner]

Hi,

I benchmarked Mingo's latest low-latency patches (2.2.10-N6 a bit modified)

The patches give me excellent results with sporadic very 2.9ms peaks !

See the testresults here:
http://www.gardena.net/benno/linux/audio/2.2.10-n6b/index.html

You can get the patch here:
http://www.gardena.net/benno/linux/audio/patches/lowlatency-2.2.10-N6B.patch

More details on my audio page.

Unfortunately the patch has still some problems , not latency-related:

- The ISDN hisax driver (my card is a Fritz classic) crashes the kernel at
modprobe hisax.o
(does not happen on an unpatched 2.2.10 kernel)   
Can someone of the ISDN maintainers please reproduce/fix this ?
(maybe a race at module initialization ?) 

- The disk performance decreases by 10-25% when I increase the CPU load in
the "latencytest" bench.
(On light CPU load there are no disk performance differences,
maybe this is related to higher scheduling overhead)

I think most of us want to have these "low-latency" features in the upcoming
2.4 kernel since it will make Linux a very good _MULTIMEDIA_OS_.

With Mingo's patches the Linux low-latency performance comes very close
to BEOS, and is much much better (3-4 times) Windows on the same hardware.
It's now time to stress audio-software vendors to port their cool apps to Linux.

comments ?


PS: To Microsoft's Anti-Linux team: just download the patch and compare the
performance with your crappy DirectX API :-)

regards,
Benno.


--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

Re: Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles

[Ingo Molnar]

On Sat, 28 Aug 1999, Benno Senoner wrote:

> - The disk performance decreases by 10-25% when I increase the CPU load
> in the "latencytest" bench.  (On light CPU load there are no disk
> performance differences, maybe this is related to higher scheduling
> overhead) 

just in case anyone misunderstood the above result (as i think many did). 
The 'CPU load' mentioned above is a _realtime process_ (unless Benno you
changed the benchmark). This is a _good_ result.  'increase CPU load'
simply means 'generate more RT load' - which in _this case_ might mean
less disk performance - but the RT task asked for it in the first place.
All in one: i can see no problem here.

if a 'simple' CPU-user (non-RT) is getting more active there is no
slowdown.

-- mingo

Re: Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles

[Benno Senoner]

On Sun, 29 Aug 1999, Ingo Molnar wrote:
> On Sat, 28 Aug 1999, Benno Senoner wrote:
> 
> > - The disk performance decreases by 10-25% when I increase the CPU load
> > in the "latencytest" bench.  (On light CPU load there are no disk
> > performance differences, maybe this is related to higher scheduling
> > overhead) 
> 
> just in case anyone misunderstood the above result (as i think many did). 
> The 'CPU load' mentioned above is a _realtime process_ (unless Benno you
> changed the benchmark). This is a _good_ result.  'increase CPU load'
> simply means 'generate more RT load' - which in _this case_ might mean
> less disk performance - but the RT task asked for it in the first place.
> All in one: i can see no problem here.

Ingo, you are right: I just ran the unmodified latencytest and was measuring 
disk performace.
In my example I used 1.45ms fragments, this means that my realtime thread
has to be rescheduled about 600times/sec ,
and during each 1.45ms cycle the rt thread wastes about 1.1ms (= 80% of 1.45ms)
of the CPU.


If you lower the CPU load to low values ( 10% for example) , there is not a big
substantial disk WRITE performance loss compared to an unpatched kernel.

The interesting thing is that the disk READ performance is unaffected by your
patches, on CPU loads of 80% I get the same disk READ performance on 
your lowlatency-N6 kernel as on a standard kernel.
Perhaps the problem lies in your modifications in the disk write code ?


> 
> if a 'simple' CPU-user (non-RT) is getting more active there is no
> slowdown.

I don't tested this yes, but I think you are right.
(Will report back some numbers when I get the benchmarking done).

You said your patch was 100% stable: are we talking about the same patches ?
The latest I got was -N6 + shm.c backed out + Roger's conditional_schedule()
wrapping in filemap.c.

The kernel is rock solid , except it crashes when I do a modprobe of the ISDN
hisax.o module.

regards,
Benno.