David Taylor wrote:
I haven't used "broadcast" or "auth", so I don't know if that affects things. My understanding of NTP was that unless you configure it otherwise, an offset exceeding 128 milliseconds would force NTP to step the PC's clock rather than changing the rate, so I am surprised you are seeing 500 ms offsets.
ntpd will wait a considerable amount of time before accepting that the time it has really is broken. That I think is the issue here. There is a tinker option which will reduce that. However the fundamental problem is that NTP is intended to be used with time sources that behave like UTC, with the only perturbations being those due to variations in network delays, etc. The OP is asking the system to work with a fundamentally broken time source. To get anything like that to work, he is going to have to tune things a very long way from their best practice settings, and accept that the ability to do so is not part of the core requirements for ntpd.
The best solution is to fix the time source, but I suspect there is some reason why that is not an option.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
