[time-nuts] NTP jitter with Linux

Gmail bownes at gmail.com
Thu Apr 5 05:36:37 UTC 2012


Indeed, I'm looking forward to getting a few raspberry pis to play with. NTP is but one of the interesting time related projects possible with a $35(us) Linux platform. The system has a number of i/o pins directly exposed that will make interfacing interesting. 

On a side note, speaking of deterministic systems, why has no one built a GPSDO with an FPGA yet? Or an NTP server? :)

Bob



On Apr 5, 2012, at 1:15, MailLists <lists at medesign.ro> wrote:

> 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.
> 
> _______________________________________________
> 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 mailing list