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

Thierry MARTIN thierry-martin at ifrance.com
Thu Feb 21 14:21:38 UTC 2008

Hello Serge,

You're right! I missed the -b option in ntpdate.

 > That's very doable, but requires some amounts of efforts. ;-)
I understand that.

The system is a "transportable" system. It is used to mesure some 
transmission time over a network (packets contain utc timestamp 
themselves). It can be moved to different sites in the network.

I would like to avoid the user of the system to wait for "one day" 
before he gets realiable results. The system is a "blackbox", which is 
suppose to work "out of the box".

Also, in this context, "setting up a DCF77 or GPS refclock" is not 
always possible (we actually do support NTP + GPS refclock).

Maybe I should look for a pci board that is able to keep good time - 
even with offset but limited drift- with no external time source...
If anyone has ever heard of this...

Thanks for your answers Serge,

Thierry MARTIN

Serge Bets a écrit :
> Hello Thierry,
>  On Tuesday, February 19, 2008 at 16:43:10 +0100, Thierry MARTIN wrote:
>> # rm /etc/adjtime;
>> # ntpdate ntp.cines.fr;
>> # hwclock --systohc;
> This procedure sets the RTC once, but does not evaluate its drift. While
> adjtimex --adjust needs to know the runtime drift rate of the RTC. So
> this should be:
> | # ntpdate -b ntp.cines.fr
> | # hwclock --systohc
> |	wait some hours (minimum 1 to 24 hours depending on hwclock
> |	version) while the machine continues to run its usual tasks
> | # ntpdate -b ntp.cines.fr
> | # hwclock --systohc
> This last command sets the RTC again *and* writes into /etc/adjtime
> the needed drift correction factor in seconds per day. Now only can
> adjtimex --adjust work correctly. Works, but is still not the best
> method to set the kernel freq, if you don't mind me to repeat. And after
> all that is finished, don't forget to set /etc/adjtime to a sane
> power-off RTC drift rate (see my next article).
> Note that the nude ntpdate without option does not set the system clock
> immediatly nor correctly. For this procedure -b (force step) is
> required. Or something better.
>> Keeping a linux system with the correct time without any external
>> synchronisation really seems hard...
> That's very doable, but requires some amounts of efforts. ;-)
> In comparision, setting up a DCF77 or GPS refclock for the ntpd daemon
> is not so deadly complicated.
> Cordialement, Serge.

More information about the questions mailing list