Re: Timers and timing, was: MySQL Performance 6.0rc1

In message <20051028093402.GT39882_at_cirb503493.alcatel.com.au>, Peter Jeremy wri
tes:
>On Fri, 2005-Oct-28 00:35:24 +0200, Poul-Henning Kamp wrote:
>>    *	Does threads have to return ordered timestamps ?
>>
>>		Consider:
>>
>>		CPU1			CPU2
>>
>>		gettimeofday(t1)
>>					gettimeofday(t2)
>>		gettimeofday(t3)
>...
>>
>>		[t1 <= t2 <= t3]
>
>If this reflects kernel threads, unless there's some sort of explicit
>synchronization between the two threads, there's no need to guarantee
>anything better than t1 <[=] t3.  If the threads are explicitly
>synchronised, then we should guarantee t1 <= t2 <= t3.

Congratulations on spotting the synchronisation issue, you were the
first to do so :-)

You are also right that we will need to talk about both kernel and
userland threads, we may want to give different levels of service.

But let me cut to the point, and show the potential for deceptive
optimization here:

We _could_ decide to make the level of service depend on the usage
of explicit synchronization.  But to exploit that, we should have
to put timekeeping hinting into all explicit synchronization
primitives.  Again, our microbenchmarks might benefit at the cost
of overall system performance.

>SunOS 4.x (I'm not sure about SunOS 5.x) did this as well.  As Poul
>pointed out, this is much easier with sane hardware.

The frustrating thing is that sane hardware is so simple to implement.

To have gotten it wrong so many times in so many ways can only
indicate that there are some really creative people in the WinTel
Marchitecture department

>FreeBSD already supports a variety of different timecounters with
>different levels of accuracy/performance/guarantees.  One problem is
>that this is a system-wide knob whereas different applications may
>have different requirements.

We _really_ don't want different programs using different hardware
for timecounting, so I hope you're just taking about the various
levels of quality supported (ie: [get]{bin,nano,micro}[up]time())

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