lkml.org 
[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectNew scheduling latencies during audio playing + heavy disk I/O on various kernels
Date
Hi,

I performed new interesting tests of the scheduling latencies
while playing audio samples from RAM.

The test was mainly performed to see if Linux can
provide a stable low-latency ( <20ms) audio I/O enviroment,
on modern machines ( PII + UDMA / SCSI drives)
for realtime applications like MIDI software synthesizers,
audio FX, harddisk recording .. , DURING HIGH DISK ACTIVITY,
at applcation level.


Unfortunately the answer is NO, with current kernels.



The benchmark is scheduled with SCHED_FIFO , with max priority.
( schp.sched_priority=sched_get_priority_max(SCHED_FIFO); )

My hardware: PII 400 Motherboard ASUS P2B , 256 MB RAM
HD IBM EDIE 16GB UDMA

---
Just for your information: under Windows I can play sound
using a *20ms* buffer and do a copy of a large file on the disk
without any dropout. ( the test was performed using
th software synthesizer NI Generator).
This to ensure that the high scheduling latencies during
disk I/O are not a hardware limitation, but a Linux limitation.

I know that the Windows programs uses some hacks like IRQ programming,
but I think with the right process/disk scheduling policies, we could
archieve similar results under Linux using rt-scheduled user processes.
---



I wrote a new scheduling benchmark which measures the maximum
scheduling latencies between two write()s to /dev/dsp , and
the number of overruns (check if the time diff is > than the audio buffer size)

The benchmark runs with several different fragmentnum/fragmentsize numbers
and summarizes the results in form of a nice table.

I tested various kernel versions: 2.0.36 , 2.2.9 , 2.2.9+andrea-patch , 2.3.5



I stressed the system in 4 ways:

- running "top" with an update frequency of 0.01 sec
(this is a mix of accessing to /proc filesystem and gfx output)
- writing a large file
- copying the file to a second file
- cat both files >/dev/null (to simulate disk read access)

( I did a separate test stressing my machine with "x11perf -all"
and using a 3x1024 bytes audio buffer = 17.5ms buffer ,
I let x11perf run for about 1 hour, and there were no dropouts, pretty good !)
(I know of some PCI gfx-cards, which freeze the PCI for too long time
during heavy graphics activity, causing sound dropouts)
Fortunately my Matrox G100 AGP, has not such problems.



to summarize:

/proc (top) test:

2.0.36 no dropouts with buffer > 17ms
2.2.5 no dropouts with buffer > 69ms *WORSE* than 2.0.36 :-(
2.2.9 no dropouts with buffer > 23ms
2.2.9-arca no dropouts with buffer > 46ms
2.3.5 no dropouts with buffer > 46ms


disk write test:

2.0.36 seems safe with buffer > 75ms
2.2.5 seems safe with buffer > 120ms
2.2.9 seems safe with buffer > 90ms
2.2.9-arca seems safe with buffer > 50-60ms
2.3.5 seems safe with buffer > 100ms

the arca patch seems to make the disk write situation a bit better

disk copy tests:

2.0.36 seems safe with buffer > 40-50ms
2.2.5 seems safe with buffer > 70-90ms
2.2.9 seems safe with buffer > 50-70ms
2.2.9-arca seems safe with buffer > 60-70ms
2.3.5 seems safe with buffer > 60-80ms

disk read test:

2.0.36 seems safe with buffer > 180-200ms
2.2.5 seems safe with buffer > 100-140ms
2.2.9 seems safe with buffer > 90-120ms
2.2.9-arca seems safe with buffer > 90-120ms
2.3.5 seems safe with buffer > 100-115ms


Detailed tables are included in the benchmark tgz (link below)


So it seems that must use at least 100-130ms of audio buffer,
during high disk activity , to ensure that there are no sound drop-outs.

I tested even a 2.2.9 kernel with a HZ=400 patch to increase scheduling
frequency , but there are no differences from a stock 2.2.9 kernel.

what helped alot is the remount of the disk in sync mode

( mount / -oremount,sync )

in this case the average scheduling latencies are very good
between 16-19ms during the disk stressing tests.


Unfortunately the disk performance sucks, the file operations are
several times slower than in async mode, therefore we can not
use the sync mode in real world.

Do you think that there exists a way to get these low scheduling latencies,
in async mode ?

I tested even the QLinux 2.2.0 , just for cursiousity,
and QLinux showed the worst latencies of all kernels,
about 200ms, maybe the cause of this was that the QLinux is a patch
for kernel 2.2.0 , and not 2.2.9 ?


If you send me some patches, I can test these on my machine,
to see if we made some progress by bringing down the
scheduling latencies to the magic 20ms.


Do you think that to archieve these results, there are
some modifications necessary, to the locking-scheme
of the I/O layer ?

I'm not a kernel hacker but IMO the problem seems
the kernel which holds some locks for too much time
during heavy disk I/O, which results in a blocking of the
write() call (to /dev/dsp).
Please correct me if I'm wrong.

Or could the locking be made more modular on a per device basis ?
( writing to /dev/dsp , has nothing to do with doing I/O on /dev/hd* ,
but it seems that some critical section locks the entire device layer
for too much time >100ms))
again, correct me if I'm wrong.

Just for curiousity, has someone made similar tests under
Solaris x86, just to have some numbers to compare ?



You can get my benchmark at

http://www.gardena.net/benno/linux/latencytest0.3.tgz


send me your results , comments and feedback, please !


regards,
Benno.


sbenno@gardena.net



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.048 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site