[time-nuts] NTP latency monitoring

[Magnus Danielson]

On 28/05/12 19:48, Hal Murray wrote:
>
> ei6iz.brendan at gmail.com said:
>
>>> Anyone tinkered with measuring GPSd, NTPd and network delay tomography?
>
>> No, but as the network admin for a reasonably large network, much of it
>> wireless I'd like to explore this
>
> If you turn on rawstats in ntp.conf, it will collect the data for you.
>
> After the classic client-server exchange, you have 4 timestamps.  That turns
> into one line in rawstats.
>
> ntpd assumes the network propagation is symmetric and computes the clock
> offset.  If you assume the clocks are correct, you can compute the network
> transit times in each direction.
>
> If you collect a bunch of data and graph it, and poke around for a while,
> it's pretty easy to get a feel for what's going on.  I split things up by IP
> Address, then show "similar" targets on the same graph.
>
> Samples with low round trip time are the ones that didn't hit any
> (significant) queuing delays.  If your routing really is symmetric and the
> clocks are accurate, the transit times should match.  If they don't match,
> you can probably figure out what's going on by looking at the graph.
> Asymmetric delays change in jumps in one direction.  Clock drift turns into a
> drift in one transit time and same drift with the sign reversed in the other
> transit time.
>
> I'll put together a few samples if anybody is interested.

If you can dig up some, it would be good.

What would be of particular interrest would be to plot the RTT and 
asymmetry of the delay over time. Another plot would be to plot 
asymmetry vs RTT. Naturally would one-way delays in both directions be 
interesting to plot vs time.

I expect that delays vary over time, and that the delay during rush-hour 
is both higher and of higher asymmetry. Such patterns will 
phase-modulate your time. The slopes will cause frequency errors naturally.

I don't trust packet delays to be symmetric, unless it's a clean pipe 
and a good design.

Cheers,
Magnus