# [SOLVED] Clock skew

## Yankee

Hi, I have read a lot of topics about this issue but so far I have not been able to solve my problem, so I will describe it here hoping that someone knows the answer.

For about two months now my local clock has been suffering from a drift, in that the system clock is too slow and loses about a minute each 10 minutes towards a reference clock.

First, I set up ntp-client and ntpd on this machine following the instructions on gentoo-wiki.com (you will find the configs below) but that did not help. Today I set up ntp-client and ntpd on my home server and used this as a time server for my faulty PC. This did not work out either. 

/etc/conf.d/clock

```

CLOCK="local"

TIMEZONE="Europe/Berlin"

CLOCK_OPTS=""

CLOCK_SYSTOHC="yes"

SRM="no"

ARC="no"

```

/etc/conf.d/ntp-client

```

NTPCLIENT_CMD="ntpdate"

NTPCLIENT_OPTS="-s -b -u pool.ntp.org"

```

For a time I had used the IP of my local time server in here.

/etc/conf.d/ntpd

```

NTPD_OPTS="-u ntp:ntp"

```

/etc/ntp.conf

```

server pool.ntp.org

driftfile       /var/lib/ntp/ntp.drift 

#restrict default ignore

restrict default nomodify nopeer

restrict 127.0.0.1

restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer notrap

```

ntpq -c pe

```

     remote           refid      st t when poll reach   delay   offset  jitter

===================================================

 time.as-compute 131.188.3.221    2 u   28   64  377  126.744  302860. 70552.2

```

Does anybody have an idea what this problem could be related to? Thanks for your help!Last edited by Yankee on Sun Jun 24, 2007 8:26 am; edited 1 time in total

----------

## jlh

That sounds like a very very serious drift and tools like ntp are probably not meant to deal with such a faulty clock.  I'm no expert, but I know that the kernel can have several sources for running its clock.  There's a 'clock' kernel boot parameter for this and you might want to try out different values (especially the default, if you're not using that one).  See /usr/src/linux/Documentation/kernel-parameters.txt and search for 'clock'.  For the details I can only refer you to google, I don't know what the various values do.  (I just see that this kernel parameter is deprecated, but I don't know what replaces it.)

It would also help to know which kernel you use and on what architecture.

----------

## Yankee

This is an x86 architecture running version 2.6.20-r8 of gentoo-sources.

----------

## beda42

did you have any luck fixing it?

A have the same problem on an 64 bit Core 2 Duo system  - large clock skew and ntpd not working. I think that it simply refuses to update such large skews.

I would appreciate any info. I tried different clock sources, but so far not luck.

----------

## Yankee

It has been working for a few days now ... magically. I don't really know why. Maybe the ntpd on my local server had to run for a longer period to stabilizy before any synching was possible.

----------

## albright

I had this problem  with an older kernel + amd64. Adding "noapic" to

the boot options fixed it at that time. Probably irrelevant but I thought

I'd mention it ...

----------

## batistuta

Please no

no

no

no

no

no

no

Ignore ntpd until you get this working. You must realize that ntpd will make solving this problem much more difficult, because it will mask the problem rather than solve it. You need to get your clock to work correctly before using ntpd. Ntpd should be used for fixing drifts of a second every month or so, not a 10% clock drift. I strongly encourage you to deactivate ntpd until you solve your drift first.

That said, here are some ideas. First, I've read about this acpi problem on amd64. Which arch are are you runnig?

Another issue is the kernel "auto drift" adjustment. When your HW clock and system clock are initially too off, Linux will get confused and make your life miserable forever. How to fix it? You need to reset this automatic HW adjustment. This file is /etc/adjtime

So do the following:

Check the acpi option as reported by albright

remove file

```
rm /etc/adjtime
```

set date accordingly

```
date MMDDhhmm[[CC]YY][.ss]
```

set the hw clock 

```
hwclock --utc --systohc
```

adjust your clock

```
nptd
```

remove file

```
rm /etc/adjtime
```

set the hw clock 

```
hwclock --utc --systohc
```

And report back results   :Very Happy: 

----------

## beda42

I have finally managed to fix it. I tried several suggested kernel options and their combinations without any luck.

To give it a last try I updated kernel from 2.6.20-r8 to 2.6.21-r3 and the problem finally went away using "ec_burst=1" and  "noapic" options.

Thanks for replies and suggestions to anyone

----------

## beda42

Just for record. After I fixed the huge time skew using the above options the ntpd works well.

I really has no point trying to get ntpd to work when there is some deeper problem with the time source.

----------

## Yankee

Thanks for your info beda! Using gentoo sources 2.6.21-r3 and adding noapic to boot options helped me too.

----------

## ozbird

I've got the same problem on one of my machines (Pentium 4), but not two others (Athlon XP and Athlon 64 X2 respectively.)

My clock was drifting by 1 second per ntpd poll, preventing ntpd from synching with the timeserver:

```
ntpdc> show timeserver

[snip]

filter offset: 7.893697 6.922396 5.950001 4.994669

                       4.008641 3.052613 2.051247 1.079833
```

Update: Apart from the different CPU, the Pentium 4 box was running with a kernel timer frequency set to 300Hz rather than 250Hz or 1000Hz on the AMD boxes.

After changing it to 1000Hz, the time skew is down to around 0.015 seconds per poll at first, which was low enough for ntpd to sync with the timeserver:

```
filter offset: 0.144171 0.135298 0.123730 0.112069

                       0.100598 0.089600 0.065919 0.050556
```

While there is some variation in the time offsets, it does seem to be decreasing over time as ntpd gets a handle on the clock drift.

Update 2:  I've reinstalled gentoo-sources-2.6.21-r2 with a 300Hz kernel timer, and the clock skew is much lower:

```
filter offset: 0.070095 0.064561 0.061653 0.054398

                       0.047819 0.039400 0.031234 0.021804
```

Update 3:  After switching back to 2.6.21-r3 with a 300Hz kernel timer, I can't reproduce the problem...

I guess that /etc/adjtime or the /var/lib/ntp/ntp.drift file may have become corrupted, but removing /etc/adjtime didn't help, and /var/lib/ntp/ntp.drift contained 0.000.

----------

## OldTango

 *batistuta wrote:*   

> Please no
> 
> no
> 
> no
> ...

 I have had this problem on a couple of systems for a while now, one x86 and one amd64, and its been driving me nuts.  Thanks to batistuta's advise, it appears my systems are back on track where they belong.

Thanks...............................  :Very Happy: 

----------

## J_L

I'm face similar problems.

My clock runs fast when my system is under high loads.

An emerge of apache for instance, which takes about a minute to finish will make the clock around 7 seconds faster.

If I leave the system without any load the clock is fine, but that's not really an option   :Sad: 

Any ideas?

/etc/conf.d/clock

```
CLOCK="local"

TIMEZONE="Europe/Stockholm"

CLOCK_OPTS=""

CLOCK_SYSTOHC="no"

SRM="no"

```

----------

## Yankee

 *J_L wrote:*   

> I'm face similar problems.
> 
> My clock runs fast when my system is under high loads.
> 
> An emerge of apache for instance, which takes about a minute to finish will make the clock around 7 seconds faster.
> ...

 

Did you try this:

 *Yankee wrote:*   

> Thanks for your info beda! Using gentoo sources 2.6.21-r3 and adding noapic to boot options helped me too.

 

----------

## J_L

Yes, using 2.6.22-gentoo-r8 with noapic

----------

## geoffp

Check this out:  I started having this problem when I upgraded from 2.6.22-gentoo-r2 to 2.6.22-gentoo-r8.  Now that I've gone back to 2.6.22-gentoo-r2, the problem appears to be gone -- and I'm not using any noacpi/noapic boot options.

I'm running x86 gentoo on AMD64, although I gather that doesn't matter much.

----------

## dwnoon

 *geoffp wrote:*   

> Check this out:  I started having this problem when I upgraded from 2.6.22-gentoo-r2 to 2.6.22-gentoo-r8.  Now that I've gone back to 2.6.22-gentoo-r2, the problem appears to be gone -- and I'm not using any noacpi/noapic boot options.
> 
> I'm running x86 gentoo on AMD64, although I gather that doesn't matter much.

 

I also experienced this problem today when I upgraded from 2.6.22-r5 to 2.6.22-r8, using an amd64 kernel on a Core2 Duo box. When I rebooted back to 2.6.22-r5 all worked correctly again. So, it looks like a buglet in one of the patches between r5 and r8 of the 2.6.22 kernel.

----------

## dwnoon

 *Quote:*   

> I also experienced this problem today when I upgraded from 2.6.22-r5 to 2.6.22-r8, using an amd64 kernel on a Core2 Duo box. When I rebooted back to 2.6.22-r5 all worked correctly again. So, it looks like a buglet in one of the patches between r5 and r8 of the 2.6.22 kernel.

 

Last night I installed 2.6.22-r9 and all seems to be well again. I presume someone corrected whatever the problem was in the immediately recent kernels.

----------

## solarflare

It took for me 23 and a half hours to obtain the stratum three status, with noacpi added in the kernel options:

```
# ntpq -c rv

assID=0 status=c6f4 sync_alarm, sync_ntp, 15 events, event_peer/strat_chg,

version="ntpd 4.2.4p0@1.1472-o Fri Dec 21 18:31:51 UTC 2007 (1)",

processor="ppc", system="Linux/2.6.23-gentoo-r3", leap=11, stratum=16,

precision=-20, rootdelay=0.000, rootdispersion=10.605, peer=42664,

refid=>???, reftime=cb1b4370.abf3549b  Tue, Dec 25 2007 10:53:04.671,

poll=6, clock=cb1b65f4.c94fdd0e  Tue, Dec 25 2007 13:20:20.786, state=2,

offset=0.000, frequency=39.592, jitter=683.467, noise=0.001,

stability=0.274, tai=0

# ntpq -c rv

assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,

version="ntpd 4.2.4p0@1.1472-o Fri Dec 21 18:31:51 UTC 2007 (1)",

processor="ppc", system="Linux/2.6.23-gentoo-r3", leap=00, stratum=3,

precision=-20, rootdelay=12.711, rootdispersion=767.728, peer=42664,

refid=62.236.254.231,

reftime=cb1b6834.c3f4708b  Tue, Dec 25 2007 13:29:56.765, poll=6,

clock=cb1b6925.193110ca  Tue, Dec 25 2007 13:33:57.098, state=2,

offset=42.346, frequency=40.523, jitter=685.799, noise=14.972,

stability=0.407, tai=0
```

Interesting. I was just about to write that I can't get the ntpd to work properly. My original reason to use it was that the sixxs.net tunnel servers didn't like clock skew at all.

----------

## nekromancer

I had a problem as well where the clock would just skew all the time. I did a bit of both solutions here...

I disabled ntp-client

rm /etc/adjtime

set the date

ran hwclock --utc --systohc

set the boot options "ec_burst=1" and "noapic" to my 2.6.21-gentoo-x kernel

then amazingly everytime I'd start up my pc it always gave me the correct date/time.

----------

## caspar

For everyone who is interested

```
noapic ec_burst=1
```

did not help me.

I am now using

```
noapic ec_burst=1 acpi=off clock=pmtmr notsc no_timer_check
```

and this seems to work.

----------

## Txema

Hi, i'm new with gentoo but not with this error. It's been... mmm 3 years now i think, and i've finally got this little and fucking error solved ^^. Well that's not important to any of you, but i think this is: 

I solved this problem by disabling the BIOS option "Speedstep", also known as "EIST", AND adding to the boot options "noapic noapictimer".

My system:

```
$ cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 15

model           : 4

model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz

stepping        : 3

cpu MHz         : 3200.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 1

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl est cid cx16 xtpr

bogomips        : 6429.51

clflush size    : 64

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 15

model           : 4

model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz

stepping        : 3

cpu MHz         : 3200.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 1

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl est cid cx16 xtpr

bogomips        : 7046.68

clflush size    : 64

```

Obviously this is only for Intel Pentium processors.

Thank you all  :Wink: 

----------

