[time-nuts] NTP jitter with Linux

Steve . iteration69 at gmail.com
Thu Apr 5 02:41:19 UTC 2012


There are a lot of problems here.  I'm not even sure where to start, but
here goes.  ;)

I suspect if you keep within the input period, ie, of 1pps you may not see
long term problems. All the pase shifting will average out to 1 in the long
run. 1 second is a lot of time for a PC to miss, but it could theoretically
happen. Consider a page out pr fault in combination with and idle cpu and
 idle disk, or worse powered down disk.--that would be very expensive and
you may see a second or more with no signal, then all the signals show up
in a very tight window.

Back to the problem, breaking the 1pps down as far as 10micro seconds,The
most obviously problem is that you are trying to use an inaccurate clock
source(the pc) to sample a precise and accurate source. --A PC is not a
frequency standard so it can't be used for (2/f) ..(3/f) ..(n/f)
measurements. After if it could do this, we would see PC based high
precision and accuracy frequency standards.

One way to achieve your goal is to use a higher source frequency standard
to drive a  cacheless microcontroller(most like a low end 8bit model),
derive a precision timer from the high frequency source, log the 1pps
signal and apply a time stamp to each sample.  Pull those samples via
USB/Serial, whatever...  Though this all defeats the purpose of NTP doesn't
it?

I think the simple answer here is that PC architecture is not intended for
such precise, accurate measurements.


Steve



Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)...
I don't think you'll ever do it, or at least not in a way that can be peer
reviewed.



On Wed, Apr 4, 2012 at 6:22 PM, Mike S <mikes at flatsurface.com> 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 mailing list