[time-nuts] NTP jitter with Linux

Mike S mikes at flatsurface.com
Wed Apr 4 22:22:10 UTC 2012


I asked this on an NTP list, got some guesses, but no knowledgeable 
responses.

I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a 
quad core CPU. PPS source is coming into a multiport serial card, which 
/proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ 
17). It's a PCI-E card, so it would be using MSI interrupts. My 
understanding is that those aren't really "shared," in the traditional 
sense, but IDK. The kernel clocksource is TSC, which is claimed to be 
core invariant on my processor (AMD Athlon II 610e). Changing to HPET 
doesn't help.

Running normally, I'll get about +- 20 us ptp of jitter (as reported by 
ntpq -p, and in loopstats). If I load up the CPU (load average >4 is 
swell), jitter will shrink to +- 1-2 us. I've played around with 
different cpufreq setting, thinking it might be related to the processor 
speed during an IRQ varying, but that seems to have minimal impact 
(performance vs. conservative vs. ondemand).

I've also tried irqbalance, with no change in performance.

So, running a process(es) which keep the CPU completely busy reduces the 
jitter. The busier, the better. Why? I'm guessing it has something to do 
with interrupt latency, but why does a busy CPU make it more consistent 
- I'd expect the opposite? The difference is very obvious.

Is there something else I can do to keep the jitter low?

Aside: Something which I believe was discussed here a few weeks ago - 
clocksource speeds changing between reboots. I patched the kernel to 
allow statically setting the TSC frequency ( 
http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html 
). This eliminates the semi-random, often 30-40 ppm change in frequency 
reported by NTP between reboots. After tweaking, it's now consistently < 
1 us, reboots be damned. This should be in the mainline kernel! This 
made no difference to the jitter mentioned above, although non was 
expected.




More information about the Time-nuts_lists.febo.com mailing list