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

In message <20051028222454.T20147_at_fledge.watson.org>, Robert Watson writes:


>Just as an experiment, I added two new time counters:

Uhm, no, you didn't.

Time counters is some piece of hardware.

What you added was two new timescales to clock_gettime()

But that's just terminology :-)


You forgot to tell us what

	sysctl kern.timecounter.hardware

was on the machine, but I pressume ACPI-fast ?


>CLOCK_SECOND - Same as CLOCK_POOR, only truncate the nanoseconds field to
>                0, and return 1 second as the resolution via
>                clock_getres().

You could just have picked this up from the global variable time_second,
that would be even faster.


>Not surprisingly, the two above clocks measure about 
>the same (they should do), and are a lot faster than real time 
>measurements (they should be).  As currently implemented, gettimeofday() 
>appears to cost the same as CLOCK_REALTIME.


Yes, there is nothing really unexpected here.


Adding two new timescales this way is a no-brainer.

The problem with it is that nobody is going to use them until we
submit patches and then they only use them on FreeBSD (and we have
to make those patches contain backwards compat etc etc) [1]

The alternative is the degrade the quality of the standard timescales:
clock_gettime(CLOCK_REALTIME), time(2) and gettimeofday().

The question there is: are we willing to live with the fallout ?

The failure modes we introduce are intricate, usually very hard to
reproduce.

When we isolate them, the fix will be in the application code, and
will often involve sending patches with an explanation that starts
out with "you know, time may be slower on one cpu than on the other
so ..." which almost invites the "Fix your damn OS" response.


Yes, I know Linux runs faster, but they can do that because they
have thrown out the weight of the airbag, collision frame and
safety belt.

I don't think that is the FreeBSD way.


But I have no problem at all with a sysctl that allows people to
make the normal time system calls do the "fast&loose thing".  That
is why it is possible to select the TSC as timecounter with a sysctl,
even after the kernel has wimpered out on it.

But I want it clearly documented that if you set this sysctl
and you system acts up, we don't even want to hear from you
until you set it back and rebooted.

Poul-Henning

[1] And both Warner and I will keep mentioning how it still does
not do anything for the leap-second issue :-)

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