Kernel unable to adjust timeofday

Kernel unable to adjust timeofday

[Rafal]

Hello, my system (64bit Ubuntu amd64 box) drifts about 10 seconds per hour
(i.e. time visible in the system).

When I adjust the date (i.e. by ntpdate) then the adjust works (but has to
be repeated each few minutes at least).

When I use adjtime(), or when I use ntpd that uses adjtime() then the
adjustment is slower then the speed of drift.

The default rate of adjustment seems to be really low, can we set the
default adjustment rate to be a higher?




Hardware (parts from lshw)

     description: Motherboard
       product: RS780-SB700
       physical id: 0
       version: Unknox
       serial: Thu Jan 20 03:32:34 2000
       slot: Internal Cache
     *-firmware
          description: BIOS
          vendor: Award Software International, Inc.
          physical id: 0
          version: F1 (01/21/2008)
          size: 128KiB
          capacity: 960KiB
          capabilities: isa pci pnp apm upgrade shadowing cdboot bootselect
socketedrom edd int13floppy360 int13floppy1200 int13floppy720
int13floppy2880 int5printscreen int9keyboard int14serial int17printer
int10video acpi usb agp ls120boot zipboot biosbootspecification
     *-cpu:0
          description: CPU
          product: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

     *-pci:0
          description: Host bridge
          product: RS780 Host Bridge
          vendor: Advanced Micro Devices [AMD]

-- 
Rafał Maj
Software developer
http://www.limcore.com/

Re: Kernel unable to adjust timeofday

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Fri, 26 Sep 2008 15:29:53 +0200, Rafal said:
> Hello, my system (64bit Ubuntu amd64 box) drifts about 10 seconds per hour
> (i.e. time visible in the system).

First thing to do is figure out why your box has *such* a dreadfully poor
clock. You're drifting at around 3,000 parts-per-million.  NTP is only able
to deal with drifts up to 500 ppm, and most systems clocks are *much* more
stable than that (for instance, my laptop is drifting at 2 ppm at the moment).
The fact you're way outside the sane range leads to trouble...

> When I use adjtime(), or when I use ntpd that uses adjtime() then the
> adjustment is slower then the speed of drift.

... which is why you see this happen.

> The default rate of adjustment seems to be really low, can we set the
> default adjustment rate to be a higher?

The default rate is set fine.  It's simply unable to deal with insane hardware
and/or software.  What kernel are you running on it?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Kernel unable to adjust timeofday

[H. Peter Anvin]

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 26 Sep 2008 15:29:53 +0200, Rafal said:
>> Hello, my system (64bit Ubuntu amd64 box) drifts about 10 seconds per hour
>> (i.e. time visible in the system).
> 
> First thing to do is figure out why your box has *such* a dreadfully poor
> clock. You're drifting at around 3,000 parts-per-million.  NTP is only able
> to deal with drifts up to 500 ppm, and most systems clocks are *much* more
> stable than that (for instance, my laptop is drifting at 2 ppm at the moment).
> The fact you're way outside the sane range leads to trouble...
> 

There are two possibilities:

Either, his system uses a ceramic oscillator instead of a crystal.  In 
that case, you're screwed.  Those can be ±10,000 ppm or more.  The other 
is that he is on a system which has a wrong frequency crystal installed 
for what the time base expects (usually 14.31818 MHz on PCs) -- say 15 
MHz.  In that case the clock is still stable, it's just *inaccurate*.

In the latter case, the adjtimex(8) command can be used to tell the 
kernel the approximate rate the clock is ticking, and then let NTP do 
the fine-tuning.

If you have manually determined that you are gaining 244 seconds in 24 
hours of free-running operation, you would use the following formula to 
calculate the tick interval:

            S
tick =  -------- * 10000
          G + S

... where S is the real sample interval (24 hours = 86400 seconds) and G 
is the amount of time gained in that time (244 seconds in this case); if 
you are *losing* time then G would be negative.

In this case:
            86400
tick = ------------- * 10000 = 9971.8 ~ 9972
         244 + 86400

So you would set:

adjtimex --tick 9972

... in your startup scripts, before ntpd is started.

If NTP still goes off the rails, then adjust the tick value in steps of 
about 5 until you can get it to converge.

	-hpa

Re: Kernel unable to adjust timeofday

[Rafal]

H. Peter Anvin wrote:

> adjtimex --tick 9972
> 
> ... in your startup scripts, before ntpd is started.
> 
> If NTP still goes off the rails, then adjust the tick value in steps of
> about 5 until you can get it to converge.
> 
> -hpa

Hi,
after adjtimex --tick 10029 the calls to ntpdate pool.ntp.org seem to be
working:

5 Oct 03:42:37 ntpdate[13218]: adjust time [...] offset -0.318571 sec
5 Oct 03:42:44 ntpdate[13223]: adjust time [...] offset -0.318193 sec
5 Oct 03:43:14 ntpdate[13226]: adjust time [...] offset -0.317724 sec
5 Oct 03:43:49 ntpdate[13233]: adjust time [...] offset -0.326299 sec
5 Oct 03:45:01 ntpdate[13263]: adjust time [...] offset -0.325523 sec

Which seems to be improvement since previously the offset was increasing 0.1
0.2 0.3 etc, untill it reached 0.5 and then jumped to 0.

Now I will test with ntpd but I hope it will work this time;
Thanks

-- 
Rafał Maj
Software developer
http://www.limcore.com/