Didier Kryn <k...@in2p3.fr> wrote: > NTP does not adjust the RTC brutally; it seems to adjust slowly the frequency > so that synchronization happens without the process being noticeable to other > apps - it can take hours. On shutdown it saves the RTC settings in > /var/lib/ntp/ntp.drift, and (AFAIU) /var/lib/hwclock/adjtime. After some days > of running NTP, your RTC is well trimmed and does not drift much. It does not > stop running when you power-off your computer. Therefore, at startup the > discrepancy is very small - unless the battery of the RTC is dead or you > stopped the computer for a year.
Yes, that is correct operation. It can take a while to settle down initially, especially if there is a large offset to start with, but it generally settles down and should have the clocks synced within a fraction of a millisecond. If the offset is very large then it will step the clock. I have a number of embedded systems that didn't have a clock battery - and hence had no time at startup. ntpd still copes with setting the time, the timestamp in the logs jump from 00:0n:nn 01-01-1970 to the current time once ntpd gets started. Didier Kryn <k...@in2p3.fr> wrote: > I use the package simply named "ntp" in Debian repo. That is the ntp.org client. > This ntp client doesn't give up. Correct. However, I have used systems in the past which ran ntpdate at startup. From memory, this may pause the system for a while as it gets multiple times from servers and sets the clock. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
