From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 13:35:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1957116A41F; Sun, 28 Aug 2005 13:35:43 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from dr.sm.ukrtel.net (dr.sm.ukrtel.net [213.179.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DB743D46; Sun, 28 Aug 2005 13:35:41 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [213.179.237.42] (trost-dialup-3.sm.ukrtel.net [213.179.237.42] (may be forged)) by dr.sm.ukrtel.net (8.12.10/8.12.10) with ESMTP id j7SDZcLG071739; Sun, 28 Aug 2005 16:35:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4311BDAD.1010803@icyb.net.ua> Date: Sun, 28 Aug 2005 16:35:41 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050706) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1045/Sun Aug 28 15:03:55 2005 on dr.sm.ukrtel.net X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 29 Aug 2005 11:52:51 +0000 Subject: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 13:35:43 -0000 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