From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 15:28:44 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ADC1DF8 for ; Mon, 27 Apr 2015 15:28:44 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 077001378 for ; Mon, 27 Apr 2015 15:28:43 +0000 (UTC) Received: by obfe9 with SMTP id e9so85929876obf.1 for ; Mon, 27 Apr 2015 08:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WeEV2NGLyLWqzLkNXIZDADd2ZBUmhr/kNSwK7zTJSQk=; b=Q5QJb1WdPlOZ0mfVTA8ut3WtYK2AOdK60wnuonD3a36pkvsUUI9tI5wS1F+nEvWf9n iSKbrz0l3HdE1vymU6w27xpSmbo2oD1XPkowaihXZfINbFcwT/W23+vJuUts6QvHqegy WPSK4J98/INwdz+ioG3fiALGMfOxcGiFGHR+VdOwe5Yky+S/QyLNEvl4JMdDQhVpfpQI dvCgVDXPWl+nj9wuB/hK5Et1SfvsI34pR3C4jXfmXIfQy2oJ1ocPPk5loW825/LeQBEx v9PoHvc5MSnsmGGwH1ZjS3AJUsd1QQoZQLkBivW5l4SJ6orCkDH5qJ7oSUbO/d+SmrBL 6Ngg== X-Gm-Message-State: ALoCoQl2bShpHdr4Dc67FedUXaZO6rEaYrbEUXkhPh18sY5p3udM57SVfgvJvufxW0FYJP8bi6zf X-Received: by 10.202.74.71 with SMTP id x68mr9960179oia.93.1430148517356; Mon, 27 Apr 2015 08:28:37 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:9924:8266:f1b9:4d7f? ([2610:160:11:33:9924:8266:f1b9:4d7f]) by mx.google.com with ESMTPSA id w81sm11432861oia.6.2015.04.27.08.28.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 08:28:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: System clock always unsynced From: Jim Thompson In-Reply-To: Date: Mon, 27 Apr 2015 10:28:35 -0500 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E68BBCF-5E21-4189-9358-F7BA3F5BECDC@netgate.com> References: To: Christian Weisgerber X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:28:44 -0000 You can prevent stepping of the clock with the -x option of ntpd. The = issue here is that "can take a long time to converge to an acceptable = offset, about 2,000 s for each second the clock is outside the = acceptable range. During this interval the local clock will not be = consistent with any other network clock and the system cannot be used = for distributed applications that require correctly synchronized network = time.=E2=80=9D http://doc.ntp.org/4.1.0/ntpd.htm Running openntpd is a poor substitute for a real ntpd. Answering, "What *does* an ntpd daemon need to do to sync the clock?=E2=80= =9D likely requires a thesis length posting, and it likely suffices to = state that you=E2=80=99re not the first to discover that openntpd is a = poor implementation of an NTP daemon. Jim > On Apr 27, 2015, at 9:39 AM, Christian Weisgerber = wrote: >=20 > I run OpenNTPD, from ports/net/openntpd, and I've noticed that after > each reboot, the initial system time is further off. (This is quite > noticeable with OpenNTPD, since by default it does *not* jump the > clock on startup like the base ntpd does.) It's as if the RTC was > never synchronized to the system clock. >=20 > Some digging in sys/kern/kern_ntptime.c shows indeed that the RTC is > only synced if STA_UNSYNC is not set, and dumping the value of the > timex struct... >=20 > offset: 0 > freq: 2730304 > maxerror: 84860000 > esterror: 500000 > status: UNSYNC > constant: 0 > precision: 0 > tolerance: 32500000 > state: ERROR >=20 > ... reveals that the clock remains permanently unsynced. Clearly, > OpenNTPD, which uses adjtime(2) to correct offsets and ntp_adjtime(2) > with MOD_FREQUENCY to correct the frequency, doesn't handle this > quite right. >=20 > What *does* an ntpd daemon need to do to sync the clock? >=20 > The ntp_adjtime(2) man page documents struct timex in detail, but > is very vague on what all of this means. >=20 > --=20 > Christian "naddy" Weisgerber = naddy@mips.inka.de > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"