[ntp:questions] tool to collect statistics on round trip delay offset?

Karel Sandler sandler at ujf.cas.cz
Thu Oct 26 11:44:31 UTC 2006

"joe blow" <someone at msn.com> wrote:

> Are there any monitoring tools that allow you to collect statistics on the 
> round trip delay, and offset without using the data.
> On a small, self contained network, (using no routers, just cisco 
> switches), I have multiple servers that I want to be in sync to  < 1ms 
> (200-300 usec ideally). It is not so important how well these match to 
> GMT, but it is very important that they agree with each other.  They are 
> used to time tag event data that needs to be correlated across servers.
> I want to take some statistics on the measurement jitter (both offset and 
> round trip delay) of a typical NTP packet.  I envision a utility that 
> would send the UPD NTP packets, and be able to calculate delay and offset 
> from a specific server (but not use the data), but just collect them for 
> analysis later.
> I'm trying to assess how much variation there is in the NTP measurements.
> The standard out of the box NTP takes way too long to stabalize to 1 ms 
> offset.  I suspect that this is due to the time constants used to be able 
> to sync to typical NTP servers on the internet. Since my network will be 
> closed (and small - all in the same room), with only 2 NTP servers (one 
> for backup),  I'm expecting very small variations in measurements, and 
> thus only a small amount of filtering should be required.  This should 
> result in faster converging times, and the ability to respond quickly to 
> server clock frequency changes (for example, room temperature changes 
> quickly due to AC cooling loss).

In the scenario with one single timeserver I would prefer the usage of the 
authenticated broadcast. All the clients get time information every 64 
seconds, the broadcasting server can simply be replaced by another one if 
needed. As mentioned earlier in this thread, all your ntpd client servers 
can be configured on your timeserver with noselect option. Then the single 
peerstats file will contain all the information you need. The best mean 
values of broadcastdelay can also be evaluated.
Your requirement on sync under 0.2-0.3 ms could be difficult to achieve 
because of quick temperature changes. One of my stratum 2 server has the 
offset sigma ~0.17ms (without AC), but its coefficient 0.127 ppm/K is rather 

Karel Sandler

More information about the questions mailing list