[ntp:questions] Strange NTP problem on AMD Geode LX cards.

David Woolley david at ex.djwhome.demon.invalid
Sat Oct 24 11:34:30 UTC 2009


David Hawkins wrote:
> 
> (The drift file will always start at zero on these systems as they operate 
> from read only flash, the /var directory is constructed in /dev/shm at boot)

The correct cold start condition for the drift file is to be not present 
at all.  This will cause ntpd to do a frequency calibration.  If it gets 
cleared to zero every reboot, it is no use at all.  It is valid to clear 
it to a value calibrated for the specific machine.

> 
> Now from this I can only conclude its a problem with the control algorithm 
> in ntp, that under some start conditions gets stuck applying the maximum 
> compensation. If it were a problem with the hardware I would have expected

On Linux, unless you have disabled it, directly, or indirectly (e.g. by 
using -x or otherwise overriding the step limit) this code is part of 
the Linux kernel, not  part of ntpd.

> it to still be there after stopping and re-starting the ntp process. If a 
> transient problem at power up with the hardware why still stuck after 48 
> hours.

> system, they are designed to just be turned off rather than shut down, so 
> the system time never gets written to the RTC, as I understand this is 
> normally done during shutdown. (In normal use these units will be on all the 
> time)

On Linux, if the system is synchronized and you haven't done anything to 
disable the kernel discipline, the RTC is updated every 11 minutes.  I 
don't think this updates the hours or higher order digits.  This 
behaviour is somewhat controversial (I think because it introduces RTC 
errors that are larger than those that could be achieved after 
correcting for the systematic drift rate of the RTC).


> 




More information about the questions mailing list