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

On Fri, 2005-Oct-28 11:52:39 +0200, Poul-Henning Kamp wrote:
>In message <20051028093402.GT39882_at_cirb503493.alcatel.com.au>, Peter Jeremy wri
>>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())

I was thinking that if the cost differential is large enough, it might
be worthwhile using different hardware counters (especially for duration
values where you don't have to worry about getting a valid UTC time).
This would probably mean adding a system call to set a default timer
type which is part of the struct proc - upon reflection, there would be
a significant amount of kernel API churn (at least) to get this to work.

To go off on a different tangent, would it be possible to use the NTP
algorithms to synchronize the TSC?  If the TSC's all tick together
(which may be true on i386 but I believe isn't on Alpha) then all you
need is a relative offset, otherwise you need a rate multiplier as
well.  Have one kthread per CPU to manage the local TSC and (ideally)
publish the offset and ratio on a per-CPU magic data page that
everyone is discussing elsewhere in this thread.

This gives something like:
    now = magic->offset + (rdtsc() * magic->multiplier) >> magic->shift;
(though the (x*y)>>z would need to be implemented more carefully to avoid
truncation in the multiplication).

[The SunOS 4.x approach was something like 0xFFFFn000 was the page for
CPU n (or maybe n/2 - I can't remember whether they were 4K or 8K pages)
and 0xFFFFE000 was the page for the CPU you were executing on.]

-- 
Peter Jeremy