On 2013-12-11 11:35, unruh wrote:
On 2013-12-11, Brian Inglis <brian.ing...@systematicsw.ab.ca> wrote:
On 2013-12-10 15:05, unruh wrote:
On 2013-12-10, Hal Murray <hal-use...@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!
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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
