From owner-cvs-src@FreeBSD.ORG Fri Oct 21 14:47:38 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 983D116A423; Fri, 21 Oct 2005 14:47:38 +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 0195E43D67; Fri, 21 Oct 2005 14:47:34 +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 38F03BC50; Fri, 21 Oct 2005 14:47:30 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 22 Oct 2005 00:23:03 +1000." <20051021230751.Q5110@delplex.bde.org> Date: Fri, 21 Oct 2005 16:47:29 +0200 Message-ID: <30613.1129906049@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann , cvs-all@FreeBSD.org Subject: Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 14:47:39 -0000 In message <20051021230751.Q5110@delplex.bde.org>, Bruce Evans writes: >On Thu, 20 Oct 2005, Poul-Henning Kamp wrote: >> ... >> If people do stupid things like use hard steps (*settime*()) to >> correct rate problems, then they get what they deserve, including >> potentially backwards jumps in time, but the integral over time of >> all steps apart from the first one amounts to a rate correction. > >Using *settime*() isn't stupid. Using it more than once per boot is stupid, and abundantly makes it clear that precise timekeeping is not what you are attempting. >> In summary: CLOCK_MONOTONIC is our best estimate of how many SI >> seconds the system have been runing [3]. > >Actual testing shows that CLOCK_MONOTONIC, or possibly CLOCK_REALTIME >less the boot time, gives a very bad estimate of how long the system has >been running. The difference between these clocks was about 500 seconds >on all systems tested: > >% sledge: >% 1:03PM up 22:45, 1 user, load averages: 0.23, 0.08, 0.02 >% uptime 1 81900 >% uptime 2 82887 Works fine for me: sledge phk> cat > a.c #include #include int main(int argc __unused, char **argv __unused) { struct timeval boottime; struct timespec up, utc; size_t s; s = sizeof boottime; sysctlbyname("kern.boottime", &boottime, &s, NULL, 0); printf("Boottime\t%ld.%06d\n", boottime.tv_sec, boottime.tv_usec); clock_gettime(CLOCK_MONOTONIC, &up); printf("Uptime\t\t%ld.%09d\n", up.tv_sec, up.tv_nsec); clock_gettime(CLOCK_REALTIME, &utc); printf("UTC\t\t%ld.%09d\n", utc.tv_sec, utc.tv_nsec); return(0); } ^D sledge phk> make a cc -O2 -fno-strict-aliasing -pipe a.c -o a sledge phk> ./a Boottime 1129904420.816916 Uptime 1317.689747507 UTC 1129905738.506671500 sledge phk> bc [...] 1129904420.816916+1317.689747507 1129905738.506663507 Mind you, there is no way the above cannot work because that is how the math in the kernel works. >Not given, and not true. After syncing with an accurate external clock >by a step, we know the real time very accurately. Normally we sync >soon after booting. Then we know the boot time very accurately (it >is the current real time less CLOCK_MONOTONIC). Then if we resync >with the external clock later using a step, we again know the real >time very accurately, [...] But have resigned ourselves to not caring about the actual length of seconds and therefore, presumably, having no serious interest in timekeeping quality. -- 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.