Re: [time-nuts] NTP latency monitoring
On 03/06/12 12:34, Magnus Danielson wrote: On 28/05/12 19:48, Hal Murray wrote: ei6iz.bren...@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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP latency monitoring
On 28/05/12 19:48, Hal Murray wrote: ei6iz.bren...@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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP latency monitoring
On Wed, 23 May 2012 13:07:41 +0930 "Kim, VK5FJ" wrote: > Anyone tinkered with measuring GPSd, NTPd and network delay tomography? Actually, we had someone else asking questions how to build an ultra stable oscillator as a reference clock for network delay measurements a couple of months ago. Search for "[time-nuts] Low-long-term-drift clock for board level integration?" in the maillinglist archives (February 2012). Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago? ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP latency monitoring
ei6iz.bren...@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. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP latency monitoring
On Wed, 2012-05-23 at 13:07 +0930, Kim, VK5FJ wrote: > Hi guys, > > About 40 minutes in ESR talks about bufferbloat and NTP skew issues; > >https://plus.google.com/118131797905622113230/posts/FBTdvYhR8qS Thanks for posting this. It kicked off quite a bit of tinkering here I also 'blue wire' modded a cheap USB GPS stick I had laying around here with rather decent results http://ei6iz.com/?p=108 > 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 -- 73 Brendan EI6IZ ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] NTP latency monitoring
Hi guys, About 40 minutes in ESR talks about bufferbloat and NTP skew issues; https://plus.google.com/118131797905622113230/posts/FBTdvYhR8qS Anyone tinkered with measuring GPSd, NTPd and network delay tomography? regards, Kim -- http://vk5fj.blogspot.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
