In article <[EMAIL PROTECTED]>, Jan Ceuleers <[EMAIL PROTECTED]> wrote:
> - the ntpd development team don't think it is a good idea to re-resolve > before _every_ poll/query, but do think it is a good idea to do this What may not have been clearly pointed out is that re-resolving is a very expensive operation for ntpd, as the standard resolver libraries are blocking, so, to avoid blocking ntpd itself, it has to spawn a separate process to do the resolution. (This actually generates a relatively frequently asked question because people see two processes when it is starting and thing something has gone wrong.) > I was wondering what the impact of such re-resolving behaviour would be > on the pool. Both cases are relevant, I think: best-practice recommended It would be a serious problem for clients of the pool as it would cause them to hop servers, thus invalidating the statistics previously accumulated, every time that TTL ran out. pool names are expected *not* to resolve to the same machine on each request. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
