From owner-cvs-all@FreeBSD.ORG Fri Oct 21 15:45:51 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5F6816A41F; Fri, 21 Oct 2005 15:45:51 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 150D743D45; Fri, 21 Oct 2005 15:45:50 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9LFjnGJ023707; Sat, 22 Oct 2005 01:45:49 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9LFjkQo009979; Sat, 22 Oct 2005 01:45:47 +1000 Date: Sat, 22 Oct 2005 01:45:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <30613.1129906049@critter.freebsd.dk> Message-ID: <20051022011020.T5554@delplex.bde.org> References: <30613.1129906049@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 15:45:51 -0000 On Fri, 21 Oct 2005, Poul-Henning Kamp wrote: > 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. How do you resync laptops after suspending them for long enough for the clock to drift? Use ntpd and let it step, or use ntpd -x and let it take hours to resync? The right thing to do is step the clocks to the current time immediately so that they are correct while the system is actually being used. [>>> Given that CLOCK_MONOTONIC gives our best idea of the uptime] >> 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. I certainly care about errors of 1 microsecond (although I don't need to), and just remembered that I use stepping to fix up the clock after sitting in ddb with the clock stopped. This reduces the error in the real time clock to ~1 microsecond per second stopped, but gives an error of 1 second per second stopped in the monotonic time and the boot time. Here the correct treatment is to jump the monotonic time forward and not touch the boot time. Bruce