Quoting Hal Murray <[email protected]>:
[email protected] 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.
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
