timecounter and Hz quality in kern RELENG_6

[martinko]

Oliver Fromme wrote:
> Michael Schuh <michael.schuh at gmail.com> wrote:
>  > i be very surprised about the performance of RELENG_6.
>  > Congratulations to the entire Team for this very good work.
>  > 
>  > Now i have 2 Machines installed with 6.0-RC1, and i have seen that on
>  > both machines the Hz is differntly with GENERIC-Kernel.
> 
> "sysctl kern.clockrate" tells you the HZ value.
> In FreeBSD 6 the dafult is 1000, unless you change
> it via "options HZ=x" in your kernel configuration.
> 
> The values from systat(1) or vmstat(8) are not reliable,
> because the counters are only 32bit and can overflow.
> For example, one machine here with HZ=1000 reports only
> 428 in "vmstat -i":
> 
>    $ sysctl kern.boottime ; date +%s ; vmstat -i | grep clk
>    kern.boottime: { sec = 1123867316, usec = 744735 } Fri Aug 12 19:21:56 2005
>    1131378875
>    clk irq0               3216967596        428
> 
> Dividing the counter value by the uptime (in seconds)
> seems to confirm the bogus rate of 428:
> 
>    $ runtime='( 1131378875 - 1123867316 )'
>    $ echo '3216967596 / $runtime' | bc
>    428
> 
> But the 32bit counter has already overflowed once, so
> we have to add 2^32.  This gives the correct value:
> 
> $ echo '( 3216967596 + 2 ^ 32 ) / $runtime' | bc
> 1000
> 
>  > After digging in the source i have found that timec.c have an routine for
>  > computing the so called "Hz quality".
> 
> During boot, the kernel probes several time counters and
> assigns "quality" values.  Typically you have three of
> them (i8254, ACPI, TPC).  The time counter with the
> highest quality value will be used for timing by default,
> but you can change it via sysctl if you know what you are
> doing.  Type "sysctl kern.timecounter" and see the result.

are those quality values preset (i.e. TSC = 800) or are they computed 
(during boot) somehow? and if the latter, how pls??

> 
>  > Can anyone explain me the "mystics" behind Hz quality,
>  > and why or how this quality is computed and what are the
>  > efforts?
> 
> The reason for that is to have a time counter that is as
> precise and reliable as possible.  For example, TPC has
> issues on SMP and power-managed machines, therefore it is
> not as reliable as ACPI, so usually the ACPI timecounter
> has higher quality (although it takes more clock cycles
> to query it).
> 
> Oh, there's also a timecounter called "dummy", which does
> not count time at all.  :-)   It exists for debugging
> purposes only, AFAIK, and has a negative quality value,
> so it is never selected automatically.
> 
> Best regards
>    Oliver
>