Testing ntpd and/or timing from gpsd

[Dan Drown]

Quoting Hal Murray <hmurray at megapathdsl.net>:
> dan-ntp at drown.org said:
>> I've found the built-in measurement to be useful.  I have this
>> configuration:
>
> Yes, but you have to be suspicious.  Consider a PPS over USB setup without
> any fudging.  Without any other clock sources, you can't tell that the
> histogram is actually offset rather than centered around zero.

I agree, you don't know if there's an offset difference just looking  
at the local clock statistics.  An example source of this offset would  
be using the wrong edge of the PPS :).  To know that you need other  
sources of time to compare against.  Lower delay/jitter sources will  
give you better information.

>> statistics loopstats peerstats clockstats
>
> rawstats is interesting too.  If you have good clocks at both ends, you can
> see network asymmetries.

Asymmetries is what I use the offset+rtt/2 and offset-rtt/2 lines for:

https://dan.drown.org/vps3/remote-ntpgps.mci.png

You can see from that graph, the request path (in green) changed on  
the 23rd.  It was going Dallas -> Kansas City, but now requests go  
Dallas -> Chicago -> Kansas City.  The response path was not rerouted.  
  You can also see that there's more jitter on the request path  
compared to the response path (in blue).

My home connection is a cable, which has asymmetric latency (and  
jitter) built into it.  DOCSIS downstream is one transmitter and  
jitter mainly comes from the queue.  DOCSIS upstream is multiple  
transmitters that need to request a timeslot in order to transmit.   
This timeslot request latency is variable and adds a lot of jitter.

You can see this in the request jitter (in green) vs the response  
jitter (in blue) here: https://dan.drown.org/bbb/remote-tick.png

The reported offset (in purple) is affected by the request jitter.  I  
assume the spike in the response latency on the 24th was traffic  
rerouting by one of the various networks involved.

>> However, looking the data "over time" is useful to see the impact of
>> various events.
>
> That's also a good way to spot network congestion.
>
> ntpd uses the best of the last 8 samples where "best" means lowest round trip
> time on the assumption that will give the lowest distortion due to queuing
> delays.  That filter is between rawstats and peerstats.  I think the local
> refclocks always return a RTT of 0 and the filter returns the most recent
> sample when the RTTs are equal.

This makes sense.