Karen, > > Before restarting ntpd you could use ntpdate to set the clock using the -B > option to slew, rather than step, the clock to the correct time before > restarting ntpd, but your offset is so large (1260 secs), that this may take > a long time to complete. > > On an Arm/Linux system I have I did a test with your offset and my clock is > slewing at a little over 0,025 secs per minute, so the correction will need > around 14 hours to complete. >
My sums were wrong… at 0,025sec per minute, 1260 seconds correction takes (1260/0,025)/60/24 = 35 days maybe too long for you. Only other option , as Monty P suggests, is start again. Boot it in single user mode to prevent ntpd starting. Reset the clock. Remove the ntp drift file . reboot. That will probably fix it though I have known some cases where a power cycle is required as active frequency corrections were not reset by hardware on a normal boot cycle. > Mike > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
