Date: Sun, 28 Aug 2005 16:35:41 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-hackers@freebsd.org Subject: ntpd and cmos clock update Message-ID: <4311BDAD.1010803@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4311BDAD.1010803>