Rasp Pi at +/- 1 us from GPS

[Achim Gratz]

MLewis via devel writes:
> The graphs I've seen published typically show significantly more than
> 1 micro-second jitter for the various implementations of Pi machines
> as time servers.

I'm pretty sure that's comparing apples to oranges.  The only meaningful
way to compare would be to produce a PPS signal from the disciplined
rasPi and compare that to some known-better PPS with a TIC.

Anyway, with not too much effort (but a bit of care) you can get the NTP
loop offset down to below 1µs at a 16s polling interval with the sigma
in the low three-digit ns range.  There is about ±1µs of "white-noise"
jitter on the raw PPS as seen by the rasPi and relatively regular spikes
up to around 10µs (plus the occasional ones that go even further out)
that will normally be thrown away as spurious when the FLL/PLL is
locked.

Loop statistics from my rasPi 3B over the last 30 days:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20171201_231805.png
Type: image/png
Size: 32984 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171201/f6b41275/attachment.png>
-------------- next part --------------

The blip yesterday was a system update that required many services to
be restarted, the one today around noon was a loss of 3D GPS lock.

> PPC-Client adjusts for some calibrated latency, getting a jitter of
> +/-1 us, but without any of the thermal stabilizing efforts. I don't know
> how to measure if the claims are true, but the messages it's producing
> supports that.

The latency calibration does not really figure into the statistical
argument you're making about the jitter.  From the description of what
pps-client does I come away with the impression it is optimized to
following the PPS very fast.  That (if it's implemented correctly) gives
you a lower boundary on the deviation, but larger noise overall.  In
particular, it requires a very clean PPS signal as you'd get from a
timing GPS module.

In any case, once you distribute the time over LAN you will probably
find that it doesn't make much difference if you run at the 1µs or 10µs
level since it all gets swamped by the jitter on the network.  It is way
more useful to have at least three clean NTP sources on that network if
stable client timing is what you're after.

> Is there any way to access the Pi 3 1.2G/1.1G for 883 ps or 909 ps?

There's no hardware TSC on the rasPi anywhere unfortunately.  On the
rasPi 1 there is a nominally 1MHz timer called STC, this is probably
where the 1µs quoted here and there comes from and is independent of the
ARM core frequency and memory mapped on the ARM side.  The newer rasPi
models use a counter defined on the ARM side (arch_sys_counter) which
runs at the 19.2MHz of the base clock, thus has ~52ns resolution and
again independent of the core frequency.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada