Hi, David--

On May 11, 2010, at 4:50 PM, Russell, David wrote:
> The device is a piece of networking equipment and so I doubt that the crystal 
> is temperature controlled but since it is in a data center the temperature 
> and power demand is steady.

It's pretty common for system loads to be different during the day and night, 
and even if this specific machine doesn't have such a change, other machines in 
the rack, network switches, and so forth produce different levels of heat which 
mildly change ambient temps, even with good air-conditioning in the datacenter.

> If you could see the graph you would see that it seems to oscillate around 
> -3.05 us/s over a 24 hour timeframe. The graph has a pretty nice looking sine 
> wave with a 12 hour period.  I was expecting that if the "true" drift rate 
> were -3.05 then NTP would converge upon that value.  Are you saying that this 
> oscillation is typical for non-temperature (cheap) crystals or should the 
> drift look more random?  

A 24-hour period to the drift is very typical, yes.  12-hour period is more 
interesting....

> One new piece of information is that the reported delay is not even close to 
> the actual delay on the network.  For example, a sniffer trace shows that the 
> actual round trip time is 1.8ms but their NTP process is reporting the delay 
> as 3.5ms.

Are you sure something isn't measuring latency one-way, and the other isn't 
measuring the round-trip time?

 1.8 ms * 2 ~= 3.5 ms

> I am not convinced that there isn't a coding error in the implementation and 
> am trying to differentiate inherent limitations in the device such as normal 
> clock drift variance, the way that the clock is adjusted etc from a coding 
> error.  There was a coding error in the previous version so it is not too 
> unlikely that there is another one.

You're welcome to request a refund of whatever you've paid for ntpd.  :-)

> Any thoughts on validating a black box NTP process?

Sure: find a more reliable timing source-- cesium or rubidium atomic clock, GPS 
receiver, WWVB, etc-- and compare that to your ntpd timestamps.

However, typical network latency and jitter (which should be less than a 
microsecond for local gigabit switched traffic, but your latency is somewhat 
higher) means that it's tough to get time significantly more accurate than 
around a microsecond, unless you are measuring locally.

> I had not realized until I sent out the email that no attachments are 
> allowed.  Is there a way to share a graph?

Please put it on a website somewhere, and mail a link to it.

Regards,
-- 
-Chuck

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to