[ntp:questions] NTP not syncing

unruh unruh at invalid.ca
Fri Dec 6 08:45:57 UTC 2013

On 2013-12-06, Bruce Evans <bde at besplex.bde.org> wrote:
> In article <Zw6ou.573976$276.424934 at fx07.iad>, unruh  <unruh at invalid.ca> wrote:
>>On 2013-12-05, antonio.marcheselli at gmail.com
>><antonio.marcheselli at gmail.com> wrote:
>>> I understand and I apologise but I'm with a small netbook at the
>>moment and I can't do better. I'm trying to clean the posts before
>>posting them back.
>>> I'll see if I can fine an alternative. Thanks for your understanding
>>in the meantime.
>>>> -258 IS pretty high. On what kind of machine? What operating system?
>>> Same machine that was before! Supermicro motherboard, debian 5.0.7
>>>> The computer has to calibrate the timer interrupts on bootup. That
>>>> calibration can be variable. For older versions of the Linux kernel that
>>>> calibration was very variable, of the order that  you are seeing. That
>>>> seems to have been fixed on the more recent kernels. 
>>> But I only restarted the ntp service, I did not reboot the server.
>>> As it's been said, I'm concerned that if the calibration can drift by
>>200ppm I may end up over the 500ppm boundary.
>>> But I understand that the drift file will change between reboots, but
>>it will then stabilise. Now the power saving is disabled I don't see the
>>drift changing over time, which should be good?
>>Yes, power saving is definitely a problem if your system clock is using
>>tsc as the clock. The number of instructin cycles per secong changes
>>under powersaving and thus the system clock rate changes by huge
>>amounts. ( the powersaving could cause the cpu to go half as fast). The
>>only thing to do is to use some other counter as the system clock (HPET
>>should be better shouldn't it?-- I donot know how it behaves under
> Starting 5-10 years ago, many x86 systems have a TSC that isn't affected
> by power saving.  I don't have such a system, but the only problems that
> I know of on such systems are:
> - the hardware to implements such invariance makes reading the TSC much
>   slower (up from about 10 cycles on old Athlons to 50-70 cycles).  This
>   is still several times faster than reading an HPET and almost 100 times
>   faster than reading the ACPI timer.
> - There may be problems with keeping the TSCs of several cores in sync.
>   The hardware doesn't do this so transparently, and if the software
>   handles it then it makes reading the TSC even slower.
> To handle the calibration varying across reboots, under FreeBSD I just
> blow away the system calibration using a sysctl in an etc/rc file.
> FreeBSD never had large variance in TSC calibration across reboots,
> but I found the ones that it has annoying.  Most versions have a jitter
> of only a couple of parts per million (ppm), but some have a fixed
> error of about 10 ppm due to a sloppy calibration algorithm.  When
> switching to a test or reference version with worse of just different
> calibration, ntpd takes noticeably longer to sync, and syncing messes
> up the driftfile for switching back.

Do you know how the system calibrates the TSC on bootup? 

More information about the questions mailing list