Miroslav,
Careful inspection of the code, experience with the debug trace and the
evidence presented previously strongly suggests your conclusion has no
relevance. See my previous messages on the number of samples in the
clock filter. I have nothing further to offer you.
Dave
Miroslav Lichvar wrote:
On Fri, Jun 11, 2010 at 03:08:53AM +0000, David L. Mills wrote:
An hour later I disconnected the server. By second 4773 the server
became unreachable and was undeclared the system peer. ten minutes
later I reconnected the server which again became reachable and the
system peer.
You are missing the point. The bug doesn't show up if the clock
filter is filled with 8 valid samples before the connection is
blocked. There has to be at least one MAXDISPERSE sample (not the last
one).
Blocking the connection on ntpd start right after fourth reply was
recevied seems to trigger the bug reliably.
If you want to trigger it in a normal situation, you need to partially
flush the filter, let few valid samples in and then block the
connection pernamently. This doesn't work reliably and you might need
to retry it several times.
If you are using an old release version, that
might explain your results.
I can reproduce it with 4.2.6p1 and 4.2.7p32, I haven't tried
anything else.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
