[ntp:questions] How do I validate my PPS clocks?
kkp2008 at kasperkp.dk
Mon Feb 25 12:44:02 UTC 2013
On 02/25/2013 12:11 AM, bodosom at gmail.com wrote:
> I can't find or figure out how to validate my ntp results.
> I (currently) have two Linux boxes with PPS via the NMEA driver from
> Garmins (18 & 18x) and a Sure board connected to a purpose built
> NTP server. When I set up my first Garmin all of my remote offsets
> were negative which seemed unlikely so I set time1 to 5.3ms which
> also seems unlikely but which brought me into congruence with some
> nearby stratum 1 servers.
You can put tight boundaries on it by using what you have, and adding up
all the delays:
I did this measurement on the 18x:
and found the PPS, measured on the 18x before the cable, to be
When the signal has passed though 10m cable, it becomes [115ns..0.5us] slow.
Whether you are feeding PPS directly to DCD, or through an RS232 driver,
mostly only matters for noise suppression. The input propagation
delay of a typical RS232 receiver is ~500ns, and 4us more if you use a
really slow (external) RS232 driver in front of it.
So the PPS arrives on the pin of the UART chip on the motherboard [115ns
.. 5us] slow.
>From the PPS arrives, and to the kernel timestamps it, is a very long time.
I wrote this to measure it:
(you will need a linux machine, gcc, and kernel-headers to compile)
You use it on an NTP server that has had time to settle. It then does a
polled test on the port, and the result is a bracket, without interrupt
delay being a problem, within which the transition is guaranteed to have
| | |
-9 -------+ | |
-7 --------------+ |
This is from my ntp server. What it tells me is that the falling edge of
the PPS pin on the chip on the motherboard happened somewhere between 9
and 4 us before '0 seconds' on the server, that is, my server is
provably slow compared to the PPS.
My time1 value is already 42 us, but should apparently be 49 us to
compensate for the (very large) interrupt delay.
(I have an RS232 driver between the GPS and the serial port, thus I am
interested in the negative edge.)
Picking the wrong edge on the 18x gives you 20ms min, 100ms default,
error, so that's easy to spot.
The conclusion is that your path to the internet most likely has 11ms
difference in the in- and outbound delays.
More information about the questions