[ntp:questions] high precision tracking: trying to understand sudden jumps

Unruh unruh-spam at physics.ubc.ca
Sun Mar 30 21:43:40 UTC 2008

David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>starlight at binnacle.cx wrote:

>> The clients are a rag-tag assembly of diverse systems including 
>> a Centos 4.5 Linux i686, Linux x86_64, Sun Ultra 10, Sun Ultra 80, 
>> IBM RS/6000 44p, Windows 2003 X64, and a Windows XP laptop.

>How are you interpolating the 16ms ticks on the Windows system?  How are 
>you disabling power management on the lap top?

>> It generally is working well, with the systems tracking anywhere 
>> from +/- 100 microseconds to +/- 500 microseconds most of the 
>> time.

>How are you measuring the difference from true time?  In principle, if 
>ntpd can measure it, it will correct it.

I expect that he means the offsets that ntp measures. NTP does NOT correct
random offsets. Ie, if there is noise source which makes the offsets vary
by 500usec ntp will not get rid of them. You will see them in the offsets
as measured by ntp. Now, the time keeping might (or might not) be more
accurate than that, but those offsets are what I suspect he means.

>> However once or twice a day, all the systems experience a 
>> random, uncorrelated time shift of from one to several 
>> milliseconds.  Had an issue where a UPS voltage correction shift 

>In which direction is the slip?  Backward only slips against true time 
>(these might appear as forward slips if the real error is in the server) 
>are typically due to lost clock interrupts.  If that is the case it 
>implies you are using a tick rate of other than 100Hz.  Please note that 
>the Linux kernel code is broken for clock frequencies other than 100Hz 
>and the use of 1000Hz significantly increases the likelihood of a lost 

He claims on all the systems. 

>The normal source of lsot interrupts is disk drivers using programmed 

Almost all disk drives on Linux now use dma.

>> and cheap power supply on the Windows X64 box appeared to be a
>> problem, but that was fixed by configuring the UPS to consider 
>> 110V nominal instead of 120V.

More information about the questions mailing list