kern.timecounter TSC/HPET/ACPI etc.

[Winston]

A funny thing happened after my recent firmware and software upgrades --
the time-of-day time (as shown by date(1)), which used to run ~1 sec/day
slow now runs ~5 sec/day fast. It looks like the cause is a change in
the measured TSC-low frequency:

typical before value:
Timecounter "TSC-low" frequency 13282498 Hz quality 800

typical after value:
Timecounter "TSC-low" frequency 13281541 Hz quality 800

and 86400 sec/day * 13282498 / 13281541 - 86400 is +6.23 seconds/day.
(Translation: The old estimate of frequency was too high, so the clock
ran slow, and the new estimate is too low, so the clock runs fast. The
actual frequency looks to be about 13282340.)

However, I see that sysctl reports:

kern.timecounter.choice: TSC-low(800) ACPI-safe(850) HPET(950) i8254(0) dummy(-1000000)
kern.timecounter.hardware: HPET

which looks to me like HPET is preferred over TSC-low and that HPET is
being used for time keeping, not TSC. The reported HPET frequencies
haven't changed.

* Are the HPET and TSC frequencies related in hardware (i.e., if TSC
frequency changes by 0.001%, would the actual, not declared, HPET
frequency change similarly?

* Setting kern.timecounter.tc.TSC-low.frequency:

Doing "sysctl kern.timecounter.tc.TSC-low.frequency=13282340" gets:
sysctl: oid 'kern.timecounter.tc.TSC-low.frequency' is read only

Would it work any better from /etc/sysctl.conf, or is it read-only
then, too?
If it's settable, is setting it there a Bad Idea for some reason?

Is the system using just HPET, and, if so, would setting
TSC-low.frequency be useless?

* Changing kern.timecounter.tc.HPET.frequency from 14318180:

What I've read so far suggests HPET frequency is a constant for all
systems. Are there any special dangers to adjusting it (if it can be
adjusted, and if that has to be adjusted instead of TSC-low)?

Thanks in advance!
-WBE

[Yes, I know about adjtime and timed. I'd like to improve the internal,
stand-alone clock time itself.]

[Bruce Evans]

In article <ydmwr9u...@UBEblock.psr.com>,

Winston <w...@UBEBLOCK.psr.com.invalid> wrote:
>A funny thing happened after my recent firmware and software upgrades --
>the time-of-day time (as shown by date(1)), which used to run ~1 sec/day
>slow now runs ~5 sec/day fast. It looks like the cause is a change in
>the measured TSC-low frequency:
>
>typical before value:
> Timecounter "TSC-low" frequency 13282498 Hz quality 800
>
>typical after value:
> Timecounter "TSC-low" frequency 13281541 Hz quality 800
>
>and 86400 sec/day * 13282498 / 13281541 - 86400 is +6.23 seconds/day.
>(Translation: The old estimate of frequency was too high, so the clock
>ran slow, and the new estimate is too low, so the clock runs fast. The
>actual frequency looks to be about 13282340.)
>
>However, I see that sysctl reports:
>
>kern.timecounter.choice: TSC-low(800) ACPI-safe(850) HPET(950) i8254(0)
>dummy(-1000000)
>kern.timecounter.hardware: HPET
>
>which looks to me like HPET is preferred over TSC-low and that HPET is
>being used for time keeping, not TSC. The reported HPET frequencies
>haven't changed.

Probably a configuration error (in the default configuration). TSC-low
apparently works (since it worked before), so it should be preferred.

>* Are the HPET and TSC frequencies related in hardware (i.e., if TSC
> frequency changes by 0.001%, would the actual, not declared, HPET
> frequency change similarly?

Clock frequencies are often related in hardware (the i8254 and TSC are
on all my systems), but I don't have a system with an HPET so I don't
know if its frequency is usually related. Of course, the hardware can
do anything that works.

>* Setting kern.timecounter.tc.TSC-low.frequency:
>
> Doing "sysctl kern.timecounter.tc.TSC-low.frequency=13282340" gets:
> sysctl: oid 'kern.timecounter.tc.TSC-low.frequency' is read only
>
> Would it work any better from /etc/sysctl.conf, or is it read-only
> then, too?

Try setting machdep.tsc_freq.

> If it's settable, is setting it there a Bad Idea for some reason?

It's a good idea for simple settings. I set various clock frequencies
in rc.local, using about 100 lines of shell code. It works to determine
the frequency very precisely by calibrating it for a few hours using ntp.
Then plug it in. The 100+ lines are because the configuration is
machine-dependent and I have about 20 combinations of machines/CPU
frequencies and I have have dynamic code to handle many cases where
the hardware or BIOS config is changed. It is most important to not
apply fixed settings when the hardware or BIOS config is changed
significantly. Signficant changes can usually be recognized by the
kernel's idea of the frequency changing by more than 1%.

For most purposes, it is easier to just use ntp. Starting ntpd with
the frequency already set correctly just lets it sync in minutes instead
of hours on new/reconfigured hardware.

I sometimes boot lots of different kernels on the same machine. Some
kernels miscalibrate the TSC more than others, or just differently.
This gives jumps like the one you observed, but often larger. Without
a fixed setting done by rc, this would cause the value in ntp's drift
file to become signficantly wrong every time the kernel is changed.

> Is the system using just HPET, and, if so, would setting
> TSC-low.frequency be useless?

Almost. You can't do much more than read (using sysctl) an inactive
timecounter to see its counter value, but the value is truncated to
32 bits.

>* Changing kern.timecounter.tc.HPET.frequency from 14318180:
>
> What I've read so far suggests HPET frequency is a constant for all
> systems. Are there any special dangers to adjusting it (if it can be
> adjusted, and if that has to be adjusted instead of TSC-low)?

Not that I know of. The constant is only its nominal frequency.

>[Yes, I know about adjtime and timed. I'd like to improve the internal,
>stand-alone clock time itself.]

Also ntp[d].

Bruce

[Winston]

I previously asked:

>>* Changing kern.timecounter.tc.HPET.frequency from 14318180:

[...]
>> Are there any special dangers to adjusting it ... ?

b...@besplex.bde.org (Bruce Evans) kindly replied:

> Not that I know of. The constant is only its nominal frequency.

> I set various clock frequencies in rc.local, using about 100 lines of
> shell code. It works to determine the frequency very precisely by
> calibrating it for a few hours using ntp. Then plug it in.

OK, good. It looks like the next thing I should try is adjusting HPET
frequency and maybe TSC frequency by .005787% in /etc/sysctl.conf.
Thanks!


> Also ntp[d].

Sure, but my current objective is to get internal time advancing at
close to the right rate rather than having to constantly adjust it from
an external time standard.

> Try setting machdep.tsc_freq.

Stuff I found via Google suggests that setting that actually sets the
CPU frequency. I'd rather not change the actual speed the system runs at.


Does anyone know where the CPU frequency (machdep.tsc_freq) number comes
from? Does FreeBSD startup code measure, calculate, or estimate it?
Is it some BIOS table entry? (I didn't spot anything in biosdecode,
"acpidump -d -t", etc. that looked like it, but maybe I missed it.)

Thanks,
-WBE

[Christian Weisgerber]

Winston <w...@UBEBLOCK.psr.com.invalid> wrote:

> A funny thing happened after my recent firmware and software upgrades --
> the time-of-day time (as shown by date(1)), which used to run ~1 sec/day
> slow now runs ~5 sec/day fast. It looks like the cause is a change in
> the measured TSC-low frequency:

Fer chrissakes, those are clock drifts on the order of xx ppm, i.e.
typical values for the PC architecture. Just run ntpd and be done
with it.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Christian Weisgerber]

Winston <w...@UBEBLOCK.psr.com.invalid> wrote:

> > Also ntp[d].
>
> Sure, but my current objective is to get internal time advancing at
> close to the right rate

For starters, make sure to keep your machines in a temperature-controlled
environment. Otherwise the clocks may not be stable over the course
of a day.

> rather than having to constantly adjust it from
> an external time standard.

ntpd calculates and applies a frequency correction (/var/db/ntpd.drift).
Once that value has stabilized, not much adjusting will happen.