ntpd and cmos clock update

Andriy Gapon avg at icyb.net.ua
Sun Aug 28 13:35:43 GMT 2005


I think I saw more than once speculations that FreeBSD updates CMOS
clock when time is set, so CMOS clock value should always be very close
to internal OS timer. But I always took it with a grain of salt because
every time I reboot after long uptime period I see messages from ntpd
about adjusting clock by many seconds and such discrepancy should not
occur, of course, during couple of minutes that reboot takes. Recently
this question (re-)surfaced in Russian language BSD newsgroup and I
thought that a wider community might be interested.

It seems that CMOS clock is updated using resettodr(9) function. There
seem to be only a few occasions when this function is called:

1. clock_settime(ClOCK_REALTIME) // through kern_time.c:settime()
2. settimeofday() // through kern_time.c:settime()
3. machdep.adjkerntz sysctl is set

I believe that ntpd calls settime-family functions only if time offset
is larger than 128ms (or maybe I am thinking about ntpdate), but
normally it uses ntp_adjtime() to adjust time keeping. Obviosuly, a
system running ntpd with good enough hardware clock and good enough
connection to good enough ntp server(s) would use the latter method all
of the time after some initial stabilization period. But it seems that
time changes are never propagated to CMOS in this case, thus leading to
behavior mentioned in the beginning.

This is not a big problem, of course, but quite an annoyance
(sometimes). I wonder what could be the best solution to this issue. One
idea is to always update CMOS from adjkerntz(8) upon shutdown/reboot,
but this would not help if system crashes, but adjkerntz could also do
it periodically.

Any ideas ? Is it worth concern at all ?

-- 
Andriy Gapon


More information about the freebsd-hackers mailing list