Date: Sat, 29 Oct 2005 14:05:50 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Pertti Kosunen <pertti.kosunen@pp.nic.fi>, Robert Watson <rwatson@FreeBSD.org>, David Xu <davidxu@FreeBSD.org>, "Yuriy N. Shkandybin" <jura@networks.ru>, current@FreeBSD.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <20051029210550.GV4115@funkthat.com> In-Reply-To: <37685.1130571501@critter.freebsd.dk> References: <20051029005719.I20147@fledge.watson.org> <37685.1130571501@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote this message on Sat, Oct 29, 2005 at 09:38 +0200:
> In message <20051029005719.I20147@fledge.watson.org>, Robert Watson writes:
>
> >It strikes me that replacing time(3) with something that retrieves
> >CLOCK_SECOND shouldn't harm time(3) semantics.
>
> It will mean that time(3) is can do minor (~1/hz) timetravel relative
> to the other calls:
>
> clock_gettime() time(3)
>
> 123.999999123
> 123
> 124.000000234
> 123
> (hardclock happens)
> 124.001020934
> 124
>
> If we can live with this, there is no problem.
This also gets into the question how do you round a second? :) I think
this is fine, or make the leap to 124 on the hardclock before we hit
124... either way, the error introduced is much less than the acuracy
returned by times, and should be safely ignored... (and the delay in
change is balanced out by the previous delay)...
If you cared that much that you were .001 seconds after 124, you'd be
using a more acurate clock...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051029210550.GV4115>