From owner-freebsd-current Thu Dec 16 9:33:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 7475514DC7 for ; Thu, 16 Dec 1999 09:33:13 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id SAA16724; Thu, 16 Dec 1999 18:32:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: nate@mt.sri.com (Nate Williams) Cc: Kevin Day , dillon@apollo.backplane.com (Matthew Dillon), gallatin@cs.duke.edu (Andrew Gallatin), freebsd-current@FreeBSD.ORG Subject: Re: Serious server-side NFS problem In-reply-to: Your message of "Thu, 16 Dec 1999 10:18:48 MST." <199912161718.KAA19547@mt.sri.com> Date: Thu, 16 Dec 1999 18:32:44 +0100 Message-ID: <16722.945365564@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912161718.KAA19547@mt.sri.com>, Nate Williams writes: >> In message <199912160758.BAA87332@celery.dragondata.com>, Kevin Day writes: >> >> >Ack, I was using this very same thing for several devices in an isolated >> >peer-to-peer network to decide who the 'master' was. (Whoever had been up >> >longest knew more about the state of the network) Having this change could >> >cause weirdness for me too... I assumed (without checking *thwap*) that >> >boottime was a constant. >> > >> >Perhaps a 'real_boottime' or 'unadjusted_boottime' that gets copied after >> >'boottime' gets initialized so that others can use it, not just NFS? :) >> >> no, I think that is a bad idea. In your case you want to use the >> "uptime" which *is* a measure of how long the system has been >> running. > >Uptime is also a constantly changing number. Forgive me for my >ignorance, but why does bootime constantly change? I would have thought >it would be a constant? I've got software that also uses this to >determine when a new copy of it exists (although I do keep a local cache >of the value in case my software crashes, since it can recover from a >crash, but not a reboot). > >I would think that boottime would be constant, since you didn't keep >booting at a different time... Well, our timekeeping is done my having two estimates: The amount of time on the UTC timescale since we booted and the time we did so in UTC. If people do a "settimeofday" we change the boot time since the amount of time we've been up *IS* known for sure, whereas the boottime is only an estimate. The ntp pll adjusts the frequency of our clock, since that is a frequency adjustment. The sticky but is the gross "adjtime" call. Since the primary user of this is the timed daemon, which issues phase adjustments, not frequency adjustments, it fiddles boottime, but still using the "slowly converge" method so we don't step the clock more than we need to. The reason why xntpd used tickadj was that enabling the kernel pll for xntpd was rather obscure and people never did. This problem is now gone with NTPv4 (Thanks Roberto!) So after today, the problem is gone, unless you use timed/tickadj or other broken clock synchronizers. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message