On 04/11/2013 18:49, Charles Swiger wrote:
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli <pu...@me.la> wrote:
Would it be wiser to delete the drift file at boot - by script - and let ntpd
resync and recreate a new drift file?
Normally, no.
The drift file lets ntpd perform a first-order correction of the average
intrinsic drift of the local clock even if ntpd can't get time from any other
sources. However, if the drift can't be computed correctly because of some
unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then
deleting the drift file might help.
Understood. I'll do some tests to find out whether with a better
configuration the drift file still gets stuck to 500. In that case I'll
have it deleted at each startup to see if things improve
As mentioned, I don't really need my system to be synced down to the
millisecond, if ntpd takes a few hours to settle and the time is off up to a
few seconds during that time it's perfectly fine with me.
Gracious. In that case, run ntpdate via cron every hour or so and you'll
probably stay within that tolerance even if ntpd itself can't manage to stay in
sync. However, if switching your system's clock source from whatever you are
using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that
would obviously provide much better timekeeping.
That is being considered. The server runs a maintenance procedure every
24hours when all the services are stopped momentarily. It could be the
right time for an ntpdate to run.
Thanks
Antonio
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
