[ntp:questions] drifting on crystal

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Fri Jan 14 09:41:15 UTC 2005

Enrique Perez-Terron <enrio at online.no> writes:

> On Thu, 2005-01-13 at 01:01, Brad Knowles wrote:
> > 	Both Linux and Windows are notorious for dropping interrupts and 
> > having even worse clocks (by orders of magnitude) than the underlying 
> > hardware is capable of.
> I wonder if this is an old truth that refuses to be forgotten, or is it
> accurate of the more recent linux kernels?
> I did read the time interrupt code some time ago (2.4 kernel), and IIRC,
> it used the TSC ("Time Stamp Counter") register to know if it had missed
> any interrupts. Also, the gettimeofday system call used the TSC register
> to interpolate the current time between interrupts.
> The clock interrupt has the highest priority of the maskable interrupts.
> Since then Linux has continually increased the granularity of its
> critical regions (i.e., the activities that require suspension of the
> interrupt system).
> It is still possible for Linux to miss a clock interrupt, if some other
> device switches off the interrupts for an extended period of time.  But
> I believe such devices are slowly dying unmaintained in the vast plains
> under /usr/src/linux/drivers/char/*.  In any case it should not bite you
> if you do not have any such device in your computer.

It all depends: Usually just test your hardware in a typical use-case: if it
doesn't loose interrupts the first day, it most likely won't the other day.

> The TSC is said to have its own problems because of variations of the
> cpu frequencies on multi-cpu computers, and because of such things as
> power saving laptops switching frequencies.  There has been some
> repeated statements about this in the glibc mailing list some months
> ago. However, those statements made no efforts to differentiate the
> situations where those problems actually apply, and no mention of the
> rather obvious possibilities the OS has to compensate for such factors.

Newer kernels (2.6) use the APIC timer (where available) which (AFAIK) uses a
constant frequency. Intel may have learned the lession. Basically one can only
use what a majority of PCs has. APICs are quite popular now.

> By the way, does ntp have support for such factors?  Do we need to
> maintain separate drift information for each of the frequencies the
> CPU(s) can switch to? 

NTP just works on the system clock. NTP is no algorithm to fix broken hardware
or algorithms. NTP just adjusts the system clock to compensate _usual_ drifts
and offsets.

This means:
1) Get your hardware right (maybe BIOS settings)
2) Get your OS right (maybe configuration)
3) get the NTP daemon right
4) Configure the NTP daemon properly

There's little sense to work on a higher number if the lower number has a
problem. MHO...


More information about the questions mailing list