Didier Kryn <kryn@???> 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 <kryn@???> 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.