[time-nuts] NTP latency monitoring

Magnus Danielson magnus at rubidium.dyndns.org
Sun Jun 3 10:44:19 UTC 2012


On 03/06/12 12:34, Magnus Danielson wrote:
> 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.

Forgot to add. Anyone interested in packet timing should look up the 
ITU-T G.8260 and G.8261 standards. There is more in the same effort, but 
it may be a good reading.

Cheers,
Magnus




More information about the Time-nuts_lists.febo.com mailing list