22 Jun
2006
22 Jun
'06
10:41 p.m.
Hi Lee
On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe
wrote:
Ok, I'll try at the higher number. I didn't have much time on this
overnight so I just ran it according to the instructions given in the README
file. I haven't had time to analyse the details.
Despite what the log says, this was running a 2.0
GHz "Dothan"
Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both
the stress tester and the monitor were run with RT privilege access.
The firewire interface used has a TI OHCI chipset.
I apologise that the run was particularly short and that therefore the
statistics aren't particularly good, but it does seem to confirm the
observations you made on your machine. The large latencies only occur
when the stress tester is running.
What if you run the latency tester at RT priority 99? Testing at 80 is
not particularly useful. If anything else is running at 99, what happens if you
lower those other
processes to 98?
What processes do you have running at RT priority 80 or above?
At the time I ran the tests there were no other usermode processes running
at any RT priority. Only the latency analyser itself and the ieee stress
tester had elevated RT priorities. Also the system hasn't had priorities of
kernel things tuned on startup - the system is a bog-standard 2.6.16-rt25
running as booted.
The system as a whole was unloaded too; I had X running with fvwm2 and some
xterms running shells but that was about it.
Does the Firewire stack do a lot of its work in
timers?
Don't know - I'll have to check.
Regards
jonathan