[LinuxPPS] ntptime status - relaunch of that issue

[Hal V. Engel]

On Tuesday 24 February 2009 12:45:03 am Michael Meier wrote:
> > I played around with different hardware and realised, that then faster a
> > machine is, then less the offset / jitter is.
> > For example on an amd64 X2 5000+ jitter/offset is about 0,100 - 0,010
> > +/- while with the Pentium M processor the offset/jitter rises up far
> > beyond 1,000...
> > I think, the Pentium M (1700MHz) should be way enough for a ntp server?
>
> The CPU Power surely is enough, but you might hit an architectural
> problem with the Pentium M: It has a timestamp counter [1] that does NOT
> increase monotonically, even when all power saving features are
> disabled. 

Where as newer amd64 CPUs have an invariant TSC that runs at one speed no 
matter what power saving mode the processor is in.  You can check amd machines 
to see if it has an invariant TSC using utilities like cpuid by looking at the 
TscInvariant line of the Advanced Power Management Features section of the 
report it produces.  If it is invariant this will return "= 0x1 (1)".  Newer 
kernels should correctly detect if the TSC counter is invariant at start up.  
Also some BIOS's for these newer amd64 processors should allow you to select 
the speed of the TSC counter as either 200MHz or 1GHz since the processor is 
designed to allow for this to be user selectable. 

> Since the TSC is the default and preferred timesource of the
> kernel, that will cause some confusion. The kernel will detect that the
> TSC is crap after some time, and switch to another source after some
> time if it has some available, but the TSC really is the best you can
> get. 

If it is invariant otherwise it is crap and should not be used.  There are two 
big advantages to using the TSC timer if it is invariant.  1. it generally has 
the highest resolution of all of the available timers/counters (100's of MHz 
compared to 10 MHz to 25 MHz for HPET and around 1MHz for acpi_pm...) and 2. 
very low CPU overhead to query the counter (100 to 1000 times as fast as off 
CPU counters like HPET and acpi_pm).   If your TSC counter is not invariant 
then you should prefer the other timers in this order:

HPET
acpi-pm
jiffies

> The only thing that comes close to it is HPET (High Precision Event
> Timer), and that is not available everywhere. 

But it should be available on any newer hardware and if available is the best 
choice for CPUs with a non-invariant TSC counter.

> And naturally, if ntpd
> cannot get the local time from the kernel with a sufficiently high
> resolution, things will start to jitter.
> You should check what your kernel currently uses as timesource (cat
> /sys/devices/system/clocksource/clocksource0/current_clocksource), and
> what sources it has available
> (/sys/devices/system/clocksource/clocksource0/current_clocksource).
> You can also check in the kernel logs, the kernel usually tells you when
> it changes the timesource and why.

Also you need to make sure that all possible timers are enabled in your kernel 
config since that would allow you to force a specific timer if for some reason 
the kernel is selecting a bad one by default by adding something like 
hpet=force as a boot parm to select the hpet timer for example.

>
> [1] http://en.wikipedia.org/wiki/Time_Stamp_Counter