On Sat, May 12, 2012 at 04:00:32PM -0700, Ask Bjørn Hansen wrote: > > 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).
All the examples I had currently don't seem to be in the pool anymore, and don't even reply anymore for a while. I think a lot of the problematic servers run openntpd. > 100ms is fine for virtually all users of the pool. If using ntpd, it will > likely pick a better clock. ntpd ussually doesn't want to lock on anything if it can't find servers that agree on the time. > 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. I can understand that. For some of the server I monitor I see the delay go up more than 100 ms during some parts of the day, and with that also the error. > >> 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. Why? I think most people want that. Kurt _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
