[ntp:questions] strange behaviour of ntp peerstats entries.

Richard B. Gilbert rgilbert88 at comcast.net
Tue Jan 29 19:58:09 UTC 2008


Brian Utterback wrote:
> Unruh wrote:
> 
>> "David L. Mills" <mills at udel.edu> writes:
>>
>>> Unruh,
>>
>>
>>> It would seem self evident from the equations that minimizing the 
>>> delay variance truly does minimize the offset variance. Further 
>>> evidence of that is in the raw versus filtered offset graphs in the 
>>> architecture briefings. If nothing else, the filter reduces the 
>>> variance by some 10 dB. More to the point, emphasis added, the wedge 
>>> scattergrams show just 
>>
>>
>> I guess then I am confused because my data does not support that. 
>> While the
>> delay variance IS reduced, the offset variance is not. The correleation
>> between dely and offset IS reduced by a factor of 10, but the clock
>> variance is reduced not at all.
>> Here are the results from one day gathered brom one clock (I had ntp not
>> only print out the peer->offset peer->delay as it does in the
>> record_peer_stats , but also the p_offset and p_del, the offset and 
>> delays
>> calculated for each packet. I alsy throw out the outliers ( for some 
>> reason
>> the system would all of a sudden have packets with were 4ms round trip,
>> rather than 160usec. These "popcorn" spikes are clearly bad. The 
>> difference
>> between the variance as calculated from the peer->offset values, and the
>> p_offset values was
>>
> 
> I do not know your network configuration at all, so I am just guessing,
> but My guess is that you are talking about a client connected on the
> same subnet with one or more servers, right? Connected by ethernet?
> 
> In that case, you are talking about a situation where the error
> introduced by factors that increase in correlation with the round
> trip time is minimal at best. When they do kick in, you see what
> looks like huge jumps and filter them. A 4ms increase is just what
> you would expect when ethernet timers kick in. Now imagine a RTT of
> 60-70ms. A 9ms delay from a collision introduces a 4ms change in the
> delay value and a 2ms change in the offset, but with a delay might not
> perturb the delay value enough to make it obviously an outlyer.
> 

I can imagine an RTT of 60-70ms.  What I have difficulty imagining is 
using such a source to synch with.  Maybe I'm just lucky but I can 
usually find servers with an RTT of 20ms or less, usually less!







More information about the questions mailing list