Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Oct 2005 18:47:16 +1000
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        Robert Watson <rwatson@freebsd.org>, current@freebsd.org
Subject:   Re: Timers and timing, was: MySQL Performance 6.0rc1
Message-ID:  <20051029084716.GY39882@cirb503493.alcatel.com.au>
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
On Sat, 2005-Oct-29 09:38:21 +0200, Poul-Henning Kamp wrote:
>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
...
>
>If we can live with this, there is no problem.

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?

>>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.

-- 
Peter Jeremy



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