Brian Utterback wrote: > Unruh wrote: > >> "David L. Mills" <[EMAIL PROTECTED]> 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! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
