[ntp:questions] drifting on crystal

Enrique Perez-Terron enrio at online.no
Thu Jan 13 22:01:19 UTC 2005


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.

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.

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? 

Regards,
Enrique
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ntp.org/pipermail/questions/attachments/20050113/83d95a7b/attachment.pgp>


More information about the questions mailing list