Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Oct 2005 01:45:47 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann <andre@FreeBSD.org>, cvs-all@FreeBSD.org
Subject:   Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] 
Message-ID:  <20051022011020.T5554@delplex.bde.org>
In-Reply-To: <30613.1129906049@critter.freebsd.dk>
References:  <30613.1129906049@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051022011020.T5554>