On Sat, 06 May 2006 20:35:07 -0400
Lee Revell <rlrevell(a)joe-job.com> 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