[ntp:questions] Sub-millisecond NTP synchronization for local network

Unruh unruh-spam at physics.ubc.ca
Fri Dec 5 01:15:21 UTC 2008


andy.helten at dot21rts.com (Andy Helten) writes:

>hal-usenet at ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote:
>>> Which linux bug causes your frequency to vary?  The only frequency issue 
>>> I've encountered is a slight variation in the dynamic boot time 
>>> measurement of the TSC (time stamp counter) frequency.  This problem is 
>>> not so much a bug in my opinion and is easily fixed by changing the 
>>> clock source to something other than "tsc".  In our system, we chose to 
>>> use acpi_pm, which so far has shown no frequency variance.  If this 
>>> isn't the issue you are having, I would be interested in which bug you 
>>> have that causes frequency variance.
>>>     
>>
>> What's your version of "slight"?  I see enough varation to
>> make an interesting startup transisent.  I doubt if anybody
>> other than a geek interested in time would notice, but if you
>> are interested in time, it's easy to notice.
>>
>> I'd call it a bug with a known workaround.
>>   

>I'd say 0.005% qualifies as slight and that is the frequency difference 

That is 50PPM. 1/10 of the maximum that ntp can tolerate. 


>I've seen from one boot to the next.  Note that when I said "slight", I 
>was referring to the measurement of the TSC frequency, not NTP's 
>reaction to it.  Sure, the fact that NTP reacts to this _slight_ 
>difference definitely makes it an issue for folks that run NTP and want 
>time to settle ASAP.  However, I generally do not take problems I don't 
>fully understand and label them bugs.  If NTP users did that, NTP must 
>be labeled as really buggy software.  For example, perhaps the linux TSC 
>issue is simply a hardware limitation in the timers used to measure the 
>TSC frequency.  Is that a bug?  Not in my book.

No. this has changed. Before about 2.6.20 kernel, the reliability of the
tsc calibration was in the few tenths of a PPM. Ie, at least 100 times
better than now. It is a newly introduced bug. 



>Just like with NTP's many nuances, the linux folks gave you alternatives 
>for when software cannot handle variations in frequency measurements.  
>Use the alternatives or please provide a good reason for why you cannot 
>use one of the alternatives.

tsc is the default. hpet destroys the real time clock for anything useful.
acpi on some bioses is broken. 






More information about the questions mailing list