Re: strange behaviour of ntp peerstats entries.

Brian Utterback wrote:
Unruh wrote:

"David L. Mills" <mills@xxxxxxxx> 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!




.

Relevant Pages

  • Re: strange behaviour of ntp peerstats entries.
    ... But the filter goes well ... The procedure does drastically reduce the variance of the delay, ... meaning that ntp suddenly has no data to do anything with for many many ...
    (comp.protocols.time.ntp)
  • Re: strange behaviour of ntp peerstats entries.
    ... variance truly does minimize the offset variance. ... the filter reduces the variance by some 10 ... delay variance IS reduced, ...
    (comp.protocols.time.ntp)
  • Re: strange behaviour of ntp peerstats entries.
    ... It would seem self evident from the equations that minimizing the delay variance truly does minimize the offset variance. ... More to the point, emphasis added, the wedge scattergrams show just how good the filter can be. ...
    (comp.protocols.time.ntp)
  • Re: strange behaviour of ntp peerstats entries.
    ... filter code. ... meaning that ntp suddenly has no data to do anything with for many many ... For example lets say that the change in delay is ... of the variance of the clock. ...
    (comp.protocols.time.ntp)
  • Re: strange behaviour of ntp peerstats entries.
    ... variance truly does minimize the offset variance. ... the filter reduces the variance by some 10 ... A 9ms delay from a collision introduces a 4ms change in the ...
    (comp.protocols.time.ntp)
Quantcast