From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 16:21:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D4A516A41F for ; Mon, 2 Jan 2006 16:21:34 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id C6E8A43D69 for ; Mon, 2 Jan 2006 16:21:20 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 02 Jan 2006 16:21:18 -0000 Received: from p5091360C.dip0.t-ipconnect.de (EHLO merlin) [80.145.54.12] by mail.gmx.net (mp031) with SMTP; 02 Jan 2006 17:21:18 +0100 X-Authenticated: #428038 Date: Mon, 2 Jan 2006 17:21:17 +0100 From: Matthias Andree To: Poul-Henning Kamp Message-ID: <20060102162117.GB14097@merlin.emma.line.org> Mail-Followup-To: Poul-Henning Kamp , current@freebsd.org References: <79206.1136213035@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79206.1136213035@critter.freebsd.dk> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Y-GMX-Trusted: 0 Cc: Matthias Andree , current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 16:21:34 -0000 On Mon, 02 Jan 2006, Poul-Henning Kamp wrote: > In message , Matthias Andree writes: > > >Are there plans to add monotonous TAI clock interfaces to FreeBSD 7 so > >we have an alternative to the differential CLOCK_MONOTONIC and the jumpy > >CLOCK_REALTIME? Is any reader of this message aware of efforts to > >standardize such a TAI clock? > > No such effort is underway, partly because it does not solve the > problems. > > First of all, TAI is not a real-time clock, it is an after the fact > paper clock. That depends on what you consider "real time" (without dash). Ask two experts and get three opinions. I don't mean to bikeshed here, I'm neutral. I'm only annoyed that POSIX pretends leap seconds were non-existant, and even more because I have no satisfactory answer to my question how FreeBSD knows that a file created at 23:59:59.2 is older than a file created at 23:59:60.1 if the timestamp is recycled but rather unsubstantiated assumptions about the amount of research I have done. I don't want to bore readers on mailing lists with epic breadth... > Second, reliably getting hold of the UTC-TAI delta is exactly the > same job as reliably getting hold of leap-second information. I'm aware of this problem, and I am aware that this is, according to Dave Mills (which he underlined again in January 2004), the showstopper that prevented NTPD from switching to TAI, because many applications desire UTC and knowing leap seconds only 6 months in advance is too short notice for autonomous appliances. > Third, it sounds like you really havn't studied this to any dept > since, quite clearly, you attack the problem from the wrong end > (making FreeBSD non-portable) rather than the right end (make > sure that computer standards represent time according to our > definition of time). Wrong, I have read up a bit (Mills, Kuhn, your posts and FAQ entries), and made up my mind - just because I'm not writing a dozen cubits of parchment full with prose doesn't mean I don't know, and I am not suggesting to warp time(3) or similar incompatible changes. (I omitted mention of Dan J. Bernstein who is also in the favor of the TAI approach because that would lead to even more bikeshedding.) Markus Kuhn suggested adding a new interface, or as an alternative solution, smoothing the UTC by slewing the clock ("UTS") for the past 1,000 seconds before the insertion or deletion of the leap second. TAI is the monotonous timescale that computers should have been using since Epoch, but I'm not sure who was there first, TAI or UNIX. Why "TAI is not a real-time clock" is irrelevant is that no-one uses internal timestamps for presentation anyways. The goals are: 1. consistent time across POSIX computers, 2. monotonic clocks inside POSIX computers (which is an extension currently), 3. a time presentation to end users that matches the astronomical view of "noon". > You can either fix POSIX to cope correctly with leap-seconds or you > can abandon leap seconds which also fixes POSIX for the future, > but adding non-standard timescales to FreeBSD will not solve the > problem. > > I think abandonning leap seconds so that POSIX becomes correct is > by several orders of magnitude the more economical solution. Does POSIX specify a solution to the problem with the ordering of the two files' age I outlined above? Not to my knowledge, so how can it possibly be "correct"? > The fact that the global network of NTP servers which are run by > the most "time" interested and motivated people in the computing > world couldn't get a leapsecond right this time only reinforces > this view. Any precendents where the leap second didn't work? URL suffices. It appears all POSIX machines I look after got the leap second right one way or another, the Linux machines slewed their clocks by 500 ppm, what the Solaris 8 machines did, I didn't check, since I have more interesting things to do on New Year's Day at 1 a.m., but they didn't log any difficulties, the FreeBSD machines were offline and resynched through ntpdate at bootup (no info), so I'm taking your word UTC remained correct. -- Matthias Andree