On Sat, May 12, 2012 at 02:20:31PM +0200, [email protected] wrote: > >I see a lot of crappy pool servers > > 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. > >Does that also mean that people could potentionally hang during > >boot because the pool command is still trying to find servers, and > >some services are waiting for ntpd to say it's started? > > No. ntpd needs always several minutes until it is operational, as > it needs to poll each server several times until it choses one. > Services shouldn't wait for that to complete. And yet people do that for some reason, and then end up in a circular dependency loop. For instance you might want to have accurate timestamps in syslog, but ntpd might want to write to syslog, so which one do you start first? And if you start ntpd first, will you make syslog wait on it? What happens when the network is down (laptop, whatever)? I have always hold having anything wait on ntp for that reason in Debian. But I see that the dovecot init script calls ntp-wait, because it kills itself if the time goes back. > 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. So basicly my question is that those 10s will now increase if the pool option is used in combination with iburst? Kurt _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
