From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 21:48:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06A5116A41F; Fri, 9 Sep 2005 21:48:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD0A43D53; Fri, 9 Sep 2005 21:48:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j89Lm8AQ006504; Fri, 9 Sep 2005 14:48:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j89Lm8Qs006503; Fri, 9 Sep 2005 14:48:08 -0700 Date: Fri, 9 Sep 2005 14:48:08 -0700 From: Brooks Davis To: Jung-uk Kim Message-ID: <20050909214808.GA6021@odin.ac.hmc.edu> References: <200509091744.26505.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <200509091744.26505.jkim@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-arch@freebsd.org Subject: Re: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 21:48:11 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 09, 2005 at 05:44:24PM -0400, Jung-uk Kim wrote: > If I read the source correctly, time_second can go backwards or=20 > forwards when there is a leap second but time_uptime cannot. Am I=20 > right? If my assumption is right, it seems we have some misuses in=20 > kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. It may not be=20 > critical but it worries me a little because a leap second is=20 > scheduled to occur at the end of this year. ;-) Yes, uptime increases monotonically, but leap seconds and adjustments such as those made by ntpdate will make simple time values jump around. This bit me when I first did the interface epochs since absolute times are not necessarily unique. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDIgMXXY6L6fI4GtQRAtQNAKCMX1XcuDcKAVttGi+93s6dzs9NtgCgtNhq AKlqajzYsIAwLnSa5kfv7tw= =ep7X -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--