[ntp:questions] FreeBSD recipe to setup for timekeeping
Brian.Inglis at SystematicSw.ab.ca
Fri Dec 13 04:36:29 UTC 2013
On 2013-12-11 11:35, unruh wrote:
> On 2013-12-11, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
>> 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
>> 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
>> 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:
>>> 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!
> Thanks for passing on to us what you learned so that some of us could
> also increase our knowledge of them. So you would say that there is NO
> micro timer which is stable under power management? That is too bad.
> I had thought that hpet was.
The timers themselves are stable, but the setup and interrupt latencies are variable,
and longer if power management is active: good enough for video work, mostly.
The best bet for now appears to be synced invariant TSCs if your system has them,
as the jitter is only the few cycles variance produced by out of order execution.
The jitter can be reduced by preceding mfence during calibration or performance timing,
but that is unnecessary when you want only a timestamp as close as possible to now.
Take care. Thanks, Brian Inglis
More information about the questions