Re: [linux-audio-dev] Re: [announce] [patch] Voluntary KernelPreemption Patch

[Lee Revell]

On Sat, 2004-07-24 at 02:43, Ingo Molnar wrote:
> * Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> 
> > jackd was running in the background in both cases.  With 1024KB, there
> > were massive XRUNS, and worse, occasionally the soundcard interrupt
> > was completely lost for tens of milliseconds.  This is what I would
> > expect if huge SG lists are being built in hardirq context.  With
> > 16KB, jackd ran perfectly, the highest latency I was was about 100
> > usecs.
> > 
> > Kernel is 2.6.8-rc2 + voluntary-preempt-I4.  CPU is 600Mhz, 512MB RAM.
> 
> ok, i'll put in a tunable for the sg size.
> 

I tested this with every power of two from 16KB to 1024KB.  The current
default on my system is 1024KB.  This may be affected by disk controller
or other factors, someone else reported a default of 128KB with the same
drive.  Using jackd at the lowest reasonable latency setting (32
frames/period at 48000 frames/sec = 666 usecs/period ), the highest
value that does not cause problems is 256KB.  The maximum latency spike
I saw with this setting was ~220 usecs.

For anyone unfamiliar, if jackd detects that it has been delayed by more
than half a period it considers this an error condition because even
though there was not an XRUN, it probably does not have enough time left
to process a block of audio, and even if it did, it would probably not
get scheduled in time to deliver it (IOW there would be an XRUN on the
next write) so it restarts.

I therefore propose 256KB as a good default for a low latency system
once this is made tunable.  This might be a good default for any system,
I am not sure under what conditions this would be a bottleneck, but for
example this would let you handle multiple NFS clients using 8K or even
32K block sizes without compromising latency.  For a single-user,
audio-centric system like a DAW, I would go as low as possible until you
see disk throughput start to drop, 16KB works well for me.

You would want this as high as possible for, say, a CD burner, but I
don't see the point is going as high as 1024KB for a disk drive.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/