[ntp:questions] FreeBSD recipe to setup for timekeeping

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Dec 11 11:54:53 UTC 2013


On 2013-12-10 15:05, unruh wrote:
> On 2013-12-10, Hal Murray <hal-usenet at ip-64-139-1-69.sjc.megapath.net> wrote:
>> Does anybody have a URL for a page that describes how to setup a FreeBSD
>> system for timekeeping?
>
> Use either chrony or ntpd.
>
>>
>> I've got a FreeBSD 9.1 system running on a 1.86 GHz Intel Atom chip.  It
>> reports TSC-low is running at 14.584185 MHz and uses it for timekeeping.
>>
>> I googled for a while, but didn't find what I was looking for.  I think
>
> You have not told us what you are looking for either.
>
>> it's tangled up with slowing down or stopping the CPU clock to save power.
>> I'm looking for a page that says do XXX to save power or do XXX to get a
>
> Do NOT use TSC for timekeeping then. You need a clock (eg I believe hpet
> for example) that does not slow down. TSC counts cpu cycles.

On Linux /proc/cpuinfo for each cpu on the power management: line there are
features and outputs showing TSC status: constant_tsc nonstop_tsc tsc_reliable.

In understand that dmidecode -t processor can display similar feature info on BSD
as well asLinux.

On Linux, tsc_reliable is based on whether all processor tscs are synced and each
CPUreturns constant deltas for a series of calibration tests, within the limits
of accuracy when you are trying to figure out what timer to use for your system.

Most processors from the last five years should pass these tests (AMD started adding
these features and fixes in 2006, and Intel has followed suit).

This may not be the case when power management is enabled, some features of which
can vary the processor power and speed behind the system's back e.g., thermal control,
as well as lock out interrupts while their needs are satisfied, increasing interrupt
latency.

So you have to disable all power management features in the BIOS (including spread
spectrum CPU speed alteration to reduce RF emissions for FCC rating) and in the OS
(e.g. Win7/CP/Power/Advanced/System Cooling Policy/Active to increase fan speed
before slowing processor) to get stable timing.

>> better clock, where XXX are probably sysctl settings.
>> kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) i8254(0) HPET(950) dummy(-1000000)

Looks like TSC is good on this system for all purposes.

>> FreeBSD 8.0-RC1 running on a 2.8 GHz Celeron is using HPET.  TSC (non low)
>> runs at 2793.170237 MHz.
>> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000)
>> I haven't figured out why it things HPET is better than TSC.

Looks like TSC calibration tests are a bit worse than ACPI and HPET, but none are perfect.
HPET was designed to provide consistent timing interrupts for media playback, not to
provide an accurate time counter; setup has to be done carefully to ensure that interrupts
will be generated, access can take many cycles (Linux enforces a minimum of 128 cycles),
and it appears that there is enough overhead using HPET to noticeably affect system
responsivess.
ACPI seems to be worse in all aspects, especially on laptops, and ignored on some other series.

For a perspective see x86: hpet: Work around hardware stupidity by Thomas Gleixner at:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=54ff7e595d763d894104d421b103a89f7becf47c

> Because it does not change when the cpu goes into power conservation?

TSC nowadays should be completely reliable if properly initialized by either the BIOS
or OS, and is designed as a real time performance monitoring facility, when HPET and
ACPI are affected by interrupt latencies, so are likely to suffer a lot of jitter.

I learned a lot more about TSC and timers than I thought I needed to know on the weekend!

-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list