On Sat, 06 May 2006 20:35:07 -0400 Lee Revell <[EMAIL PROTECTED]> wrote:
> > > Same as the existing CLI tools - it would start an RT thread that polls > > > on the RTC, then tell the user to generate some load (switch windows, > > > do a find /, pingflood the default gateway, whatever), then report back > > > the maximum latency. > > > > Could you give me some links to these tools? I know I've seen something > > like this, but I'm unable to find it... > > I think Florian Schmidt's web site has the latest latency tester. > > > How do these tools relate to the latency tracer in the realtime kernel? > > > > The tester is a userspace tool to measure low latency performance, the > latency tracer is an in-kernel mechanism to determine which part of the > kernel might be causing a latency problem. You can get the tarball from this page: http://tapas.affenbande.org/?page_id=15 [Some elaborations for the OP]: Of course, as this uses the RTC and not the soundcard it cannot account for i.e. buggy soundcard drivers [i have a cs46xx card that _always_ produces some xruns no matter how well tuned the system is. No such problems with my delta 66]. I kinda thought rtc_wakeup was obsolete these days, as the kernel tools are a much better instrument [assuming you use a -rt kernel, or does vanilla have the latency tracing et. al. stuff these days, too?]. So maybe it is still useful for a non-rt kernel. But what serious audio user would use a non-rt kernel? On a 2.6.15.4 kernel with low latency desktop setting [non-rt] i get a max jitter of [after like 5 minutes running]: new max. jitter: 68.4% (667 usec) which looks pretty good. But it seems jackd has some more weak points than rtc_wakeup [which is very simple]. For example on this kernel running jack with a periodsize of 256 at a samplerate of 48khz _seems_ to run fine even with a find / or two. But beware. Copying large files to /dev/null makes jackd sometimes produce xruns in the range of tens to hundreds of ms -> ugh. rtc_wakeup OTOH is not affected by this. I suspect the culprit is the FS [which jack depends on through its use of pipes to do the interprocess wakeup]. But only -rt instruments could tell us what's really up. It seems -rt kernels have the latency tracing mechanisms available even when not using full preemption. But i'm too lazy right now ;) Flo -- Palimm Palimm! http://tapas.affenbande.org