On May 12, 2012, at 6:23, Kurt Roeckx wrote: >> Can you elaborate? The monitoring is supposed to take out crappy >> servers, so that you shouldn't be able to see them. > > The monitoring isn't good enough. I think you need to be off by > more than 100 ms before it reacts. And I see servers going from > +100 to -100 and back all the time.
I'm surprised you see this often. Can you send me some examples? (Maybe off-list). 100ms is fine for virtually all users of the pool. If using ntpd, it will likely pick a better clock. My concern with making the limit smaller is that any problems with the monitoring system are more likely to affect things then; and from when I've looked at the numbers usually if a server goes bad, it gets worse than 100ms quickly anyway. >> The iburst feature is meant to speed this up (down to about 10s); >> somehow, this fails to work in this bug report. > > Yes, we have iburst in the config file in Debian, and I've asked > this list if they think that that's a good idea or not, since > it might increase traffic to the servers, but never got a reply to > it. I'd say it's a bad idea to have as a distributed default. If any individual users need it, fine - but distributed as the default is not a good idea. Ask _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
