From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 10:09:10 2005 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 025C516A41F; Sat, 29 Oct 2005 10:09:10 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6485843D79; Sat, 29 Oct 2005 10:09:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 104A3BC50; Sat, 29 Oct 2005 10:09:01 +0000 (UTC) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 29 Oct 2005 18:47:16 +1000." <20051029084716.GY39882@cirb503493.alcatel.com.au> Date: Sat, 29 Oct 2005 12:09:00 +0200 Message-ID: <38091.1130580540@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Robert Watson , current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 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: Sat, 29 Oct 2005 10:09:10 -0000 In message <20051029084716.GY39882@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >On Sat, 2005-Oct-29 09:38:21 +0200, Poul-Henning Kamp wrote: >Most applications will do all their timekeeping using a single set of >clock calls so I don't think this is especially serious. Does POSIX >require any guarantees about (eg) clock_gettime(CLOCK_REALTIME), time() >and gettimeofday() returning identical values? Can we claim "rounding >and truncation" to explain the discrepancies? When it comes to timekeeping (well, and pretty much everything else come to think of it) ports is much more important than POSIX. >>>It's >>>gettimeofday() that's the troubling one -- it's widely used to query the >>>time in applications, and its API suggests microsecond resolution. >> >>And we don't really have a cheap way to do that... > >If we did drop the microsecond resolution, we wouldn't be alone - it >used to be fairly common for tv_usec to increment in 1/hz steps. Even >our manpage states that it might be incremented in ticks rather than >continuously. Again, for it to be cheaper, we need to use the cached timestamps and that would open the same inconsistency as for time(3), only now the skew will happen Hz times per second instead of only once per second. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.