Timers and timing, was: MySQL Performance 6.0rc1

[Poul-Henning Kamp]

In message <20051029084716.GY39882 at cirb503493.alcatel.com.au>, Peter Jeremy wri
tes:
>On Sat, 2005-Oct-29 09:38:21 +0200, Poul-Henning Kamp wrote:

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

When it comes to timekeeping (well, and pretty much everything else
come to think of it) ports is much more important than POSIX.

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

Again, for it to be cheaper, we need to use the cached timestamps
and that would open the same inconsistency as for time(3), only
now the skew will happen Hz times per second instead of only once
per second.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.