Quoting Hal Murray <[email protected]>:
I prefer RTT rather than RTT/2.
RTT/2 suggests that the routing is symmetric which is wrong quite often.
Adding +/- RTT/2 on the graph reverses the assumption ntp uses that
the routing is symmetric. ntp already subtracts rtt/2 from the
calculated offset to estimate the one way latency. Removing that from
the equation will show you the relevant offsets of: when the request
started and when the response was received.
Here's an example of an upstream source that had the request latency
(in green) change due to routing paths:
https://dan.drown.org/vps3/remote-ntpgps.mci.png
You can see the response latency (in blue) did not change
significantly. So the sudden jump in the NTP offset (in red) was not
due to the clocks changing frequencies relative to each other, but due
to routing effects.
You can also see that after the 23rd, the new request path had a lot
more jitter that is not in the response path. This also impacts the
offset.
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
