[time-nuts] question about multi-way measurement

Achim Gratz Stromeko at Nexgo.DE
Fri Dec 28 13:45:06 UTC 2018


Charles Wyble wrote:
 > I’m using a raspberry pi with gps hat for my master time source.
 > Shortly I’ll be having a total of three systems (two using the same
 > hat, one using the adafruit hat and being a pi2). I’ve got some
 > interest in multiple way comparison and will follow this thread
 > shortly.

I'd say three doesn't really get you good enough visibility.  It depends 
somewhat on how good your GPS reception is and how stable the 
environment, especially temperature.  At around five NTP servers with 
suitable precision you start to see "interesting" things like asymmetric 
latency in your local network and can more easily throw out the 
inevitable spurs from degraded GPS reception (unless you have a really 
good antenna location).

I'd suggest you also log at least the PPS timestamps to correlate to the 
NTP logging.  NTP peer logging will be dominated by network latency and 
jitter, provided you took care to tune the residual loop error to below 
1µs.  I'm running a Perl script that also records the CPU temperature 
and system utilization synchronized with the PPS.  All my logging is 
into files at the moment, which puts some extra stress on the SD card 
that several no-name cards have not survived for long.  I've salvaged an 
SSD that I plan to connect via an USB to SATA converter and then set up 
a proper time series database on one the boxes to feed all data into. 
Alternatively you could log into a tmpfs and rotate onto SD card 
whenever you've collected a full Flash block.

I currently have seven stratum-1 NTP servers (five different rasPi and 
two TinkerBoard) on my LAN.  I've self-ovenized six of them (the 
exception is the rasPi 1B+, which simply isn't powerful enought to pull 
that off) to keep the crystal temperature very near the turnover point 
of the f vs. T curve, which leaves me with just the jitter and drift of 
the (apparent) system frequency most of the time.  The rasPi crystals 
(or the interrupt system on the SoC) are a bit noisy with seemingly 
unprovoked frequency jumps on a not too-long timescale, so that keeps 
you to within a 5ppb window after removing the drift.  The TinkerBoard 
doesn't have those jumps and I keep both routinely within 1ppb of the 
expected drift curve.  I've experimented with both low and high thermal 
mass designs, but so far I don't see a difference in timing performance 
between the two.  The high-thermal mass design does smooth out the 
external temperature swings more effectively, so with further 
refinements to the oven controller it might eventually provide a usable 
advantage.

-- 
Achim.

(on the road :-)




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