12 Jul
2004
12 Jul
'04
10:26 p.m.
On Mon, 2004-07-12 at 19:31, Andrew Morton wrote:
Lee Revell <rlrevell(a)joe-job.com> wrote:
Gnutella client. Forgot about that. I agree, it is not reasonable to
expect low latency with this kind of network traffic happening. I am
impressed it worked as well as it did.
On Sun, 2004-07-11 at 01:25, Andrew Morton wrote:
OK, thanks. The problem areas there are the timer-based route cache
flushing and reiserfs.
We can probably fix the route caceh thing by rescheduling the timer after
having handled 1000 routes or whatever, although I do wonder if this is a
thing we really need to bother about - what else was that machine up to?
What we need to do is to encourage audio testers
to use ALSA drivers, to
enable CONFIG_SND_DEBUG in the kernel build and to set
/proc/asound/*/*/xrun_debug and to send us the traces which result from
underruns.
OK, here goes. The following traces result from running JACK overnight
like so, on an otherwise idle system. Hardware is a VIA EPIA 6000, with
a 600Mhz C3 processor. Kernel is 2.6.7 + volunatary_preempt patch.
voluntary_preempt and kernel_preemption are both on.
jackd -v --realtime -d alsa --outchannels 2 --rate 48000 --shorts
--playback --period 32 --nperiods 2
These settings require less than 666 microseconds scheduler latency.
The average performance is quite good - 5-20 *microseconds*! resierfs: yes, it's a problem. I
"fixed" it multiple times in 2.4, but the
fixes ended up breaking the fs in subtle ways and I eventually gave up.
Interesting. There is an overwhelming consensus amongst Linux audio
folks that you should use reiserfs for low latency work. Should I try
ext3?
Lee