[time-nuts] NTP jitter with Linux

MailLists lists at medesign.ro
Thu Apr 5 05:15:37 UTC 2012


As a rule of thumb, any general purpose architecture will be less 
effective at a specific task than a specially designed one. That applies 
more and more to the "modern" way of solving tasks: software.
The PC is one of the classical examples of GPA, and as such it is best 
to know its limitations, so as to not have exaggerated expectations.
The first limitation, in that specific case, is the way the PPS source 
is connected to the system. LinuxPPS tries to optimize it.
The serial port is far from being a precision path, the "newer" 
implementations being optimized for throughput (FIFOs) are even worse. 
Any additional layer (USB especially) makes things just more and more worse.
As for linux itself, to increase predictability, any disturbing factor 
should be minimized, if not eliminated. That would mean especially 
laptop power consumption optimization gimmicks, which are useless in a 
high performance server/workstation environment (eco, green, and the 
other trendy marketingdroid buzzwords are lately more, and more abused 
for a few percent power consumption reduction).
The suggested RTOS approach is workable, but it represents just another 
example of tweaking a GPA to a specific task, which for a server is 
usually not desired. The low latency patches are another example, used 
usually for DAWs, but with the reverse side of increased processor loading.
First you must define what your goals, and necessities are, and then 
optimize your system for the desired task - here linux is your friend, 
with its almost unlimited tweaking options (no comparison to windumb.) 
Also, don't use a dumbed down distro, and (learn to) patch/compile your 
own special kernels (best stripped down of all useless ballast of a 
"generic" one).


On 4/5/2012 1:22 AM, Mike S wrote:
> 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.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




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