Unruh wrote: > Brian Utterback <[EMAIL PROTECTED]> writes: > >> Unruh wrote: >>> "David L. Mills" <[EMAIL PROTECTED]> writes: > >>>> You might not have noticed a couple of crucial issues in the clock >>>> filter code. >>> I did notice them all. Thus my caveate. However throwing away 80% of the >>> precious data you have seems excessive. > > Note that the situation can arise that the one can wait many more than 8 > samples for another one. Say sample i is a good one. and remains the best > for the next 7 tries. Sample i+7 is slightly worse than sample i and thus > it is not picked as it comes in. But the next i samples are all worse than > it. Thus it remains the filtered one, but is never used because it was not > the best when it came in. This situation could keep going for a long time, > meaning that ntp suddenly has no data to do anything with for many many > poll intervals. Surely using sample i+7 is far better than not using any > data for that length of time.
On the contrary, it's better not to use the data at all if its suspect. ntpd is designed to continue to work well even in the event of loosing all access to external sources for extended periods. > And this could happen again. Now, since the > delays are presumably random variables, the chances of this happening are > not great ( although under a condition of gradually worsening network the > chances are not that small), but since one is running ntp for millions or > billions of samples, the chances of this happening sometime becomes large. > There are quite a few ntpd servers which are isolated and once an hour use ACTS to fetch good time samples. This is not rare at all. Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
