[ntp:questions] no ntp synchronisation: 2s to 6s time shift !

Unruh unruh-spam at physics.ubc.ca
Tue Feb 19 21:13:58 UTC 2008


Thierry MARTIN <thierry-martin at ifrance.com> writes:

>Hi All,

>Sorry for beeing too enthousiastic about my initial test...

>I launched another test with clocksource=acpi_pm, on the same machine.
>The results are bad now (> 500ms in a few hours).

>FYI, the command I launched:
># rm /etc/adjtime;
># ntpdate ntp.cines.fr;
># hwclock --systohc;
># adjtimex -a

>Then I watch:
># ntpdate -q ntp.cines.fr

>Keeping a linux system with the correct time without any external 
>synchronisation really seems hard...

Yes. YOu expected something else?
If you use chrony, you can enter in the time by hand now and then again in
8 hours. chrony will use that data to estimate the drift of the oscillator
and use that drift info to try to keep the clock on better time. You CANNOT
expect a PC oscillator to keep good time without drift compensation. They
were never designed for that. Note that 1 sec in 10 hours is a drift rate
of only 30PPM. which is well within the error budget of most crystals. With
hand setting you can probably reduce that by a factor of 10 but not much
better due to temp variations, etc.



>Best regards
>Thierry.





>Thierry MARTIN a écrit :
>> Oups?
>> 
>> If I understand your post, tsc is the same as acpi_pm ?
>> 
>> Was I just a lucky guy with this config?
>> 
>> (:- You've just killed my enthousiasm ... :-)
>> 
>> 
>> 
>> David Woolley a écrit :
>>> Thierry MARTIN wrote:
>>>
>>>> I have been trying acpi_pm clocksource for a few days now and the 
>>>> results are quite good :-).
>>>>
>>>> The time drift is less than 1s per day (I would even say less that 
>>>> 500ms but this has to be confirmed) which is much better than the 
>>>> default config with tsc (>2s /day).
>>>
>>> It's almost certain that the same hardware time source is used for 
>>> both, so discrepancies are likely to be attributable to software 
>>> issues (although those may include problems in calibrating the 
>>> frequency of various sources empirically, rather than by knowing how 
>>> they derive from the common source).




More information about the questions mailing list