Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] Clock skew
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Yankee
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2003
Posts: 77
Location: Germany

PostPosted: Sun Jun 03, 2007 1:33 pm    Post subject: [SOLVED] Clock skew Reply with quote

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
Code:

CLOCK="local"
TIMEZONE="Europe/Berlin"
CLOCK_OPTS=""
CLOCK_SYSTOHC="yes"
SRM="no"
ARC="no"


/etc/conf.d/ntp-client
Code:

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
Code:

NTPD_OPTS="-u ntp:ntp"


/etc/ntp.conf
Code:

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
Code:

     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
Back to top
View user's profile Send private message
jlh
Tux's lil' helper
Tux's lil' helper


Joined: 06 May 2007
Posts: 145
Location: Switzerland::Zürich

PostPosted: Sun Jun 03, 2007 4:23 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Yankee
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2003
Posts: 77
Location: Germany

PostPosted: Sun Jun 03, 2007 4:42 pm    Post subject: Reply with quote

This is an x86 architecture running version 2.6.20-r8 of gentoo-sources.
Back to top
View user's profile Send private message
beda42
n00b
n00b


Joined: 08 Jun 2007
Posts: 3

PostPosted: Fri Jun 08, 2007 6:57 am    Post subject: progress Reply with quote

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.
Back to top
View user's profile Send private message
Yankee
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2003
Posts: 77
Location: Germany

PostPosted: Fri Jun 08, 2007 7:07 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
albright
Advocate
Advocate


Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto

PostPosted: Fri Jun 08, 2007 12:45 pm    Post subject: Reply with quote

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 ...
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)
Back to top
View user's profile Send private message
batistuta
Veteran
Veteran


Joined: 29 Jul 2005
Posts: 1384
Location: Aachen

PostPosted: Fri Jun 08, 2007 2:10 pm    Post subject: Reply with quote

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
Code:
rm /etc/adjtime


set date accordingly
Code:
date MMDDhhmm[[CC]YY][.ss]


set the hw clock
Code:
hwclock --utc --systohc


adjust your clock
Code:
nptd


remove file
Code:
rm /etc/adjtime


set the hw clock
Code:
hwclock --utc --systohc


And report back results :D
Back to top
View user's profile Send private message
beda42
n00b
n00b


Joined: 08 Jun 2007
Posts: 3

PostPosted: Thu Jun 21, 2007 11:42 am    Post subject: new kernel and some options fixed it Reply with quote

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
Back to top
View user's profile Send private message
beda42
n00b
n00b


Joined: 08 Jun 2007
Posts: 3

PostPosted: Thu Jun 21, 2007 11:45 am    Post subject: ..more info Reply with quote

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.
Back to top
View user's profile Send private message
Yankee
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2003
Posts: 77
Location: Germany

PostPosted: Sun Jun 24, 2007 8:26 am    Post subject: Reply with quote

Thanks for your info beda! Using gentoo sources 2.6.21-r3 and adding noapic to boot options helped me too.
Back to top
View user's profile Send private message
ozbird
Apprentice
Apprentice


Joined: 21 Oct 2003
Posts: 185

PostPosted: Wed Jun 27, 2007 2:15 am    Post subject: gentoo 2.6.21-r3 and 300Hz kernel timer breaks NTP? Reply with quote

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:
Code:
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:

Code:
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:
Code:
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.
Back to top
View user's profile Send private message
OldTango
l33t
l33t


Joined: 21 Feb 2004
Posts: 718

PostPosted: Mon Jul 02, 2007 8:51 pm    Post subject: Reply with quote

batistuta wrote:
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
Code:
rm /etc/adjtime

set date accordingly
Code:
date MMDDhhmm[[CC]YY][.ss]

set the hw clock
Code:
hwclock --utc --systohc

adjust your clock
Code:
nptd

remove file
Code:
rm /etc/adjtime

set the hw clock
Code:
hwclock --utc --systohc

And report back results :D
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............................... :D
Back to top
View user's profile Send private message
J_L
n00b
n00b


Joined: 11 Sep 2006
Posts: 68
Location: Gothenburg

PostPosted: Tue Oct 02, 2007 7:22 pm    Post subject: Reply with quote

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 :(
Any ideas?

/etc/conf.d/clock
Code:
CLOCK="local"
TIMEZONE="Europe/Stockholm"
CLOCK_OPTS=""
CLOCK_SYSTOHC="no"
SRM="no"
Back to top
View user's profile Send private message
Yankee
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2003
Posts: 77
Location: Germany

PostPosted: Tue Oct 02, 2007 7:26 pm    Post subject: Reply with quote

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.
If I leave the system without any load the clock is fine, but that's not really an option :(
Any ideas?

/etc/conf.d/clock
Code:
CLOCK="local"
TIMEZONE="Europe/Stockholm"
CLOCK_OPTS=""
CLOCK_SYSTOHC="no"
SRM="no"


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.
Back to top
View user's profile Send private message
J_L
n00b
n00b


Joined: 11 Sep 2006
Posts: 68
Location: Gothenburg

PostPosted: Tue Oct 02, 2007 7:30 pm    Post subject: Reply with quote

Yes, using 2.6.22-gentoo-r8 with noapic
Back to top
View user's profile Send private message
geoffp
n00b
n00b


Joined: 10 Oct 2004
Posts: 47

PostPosted: Wed Oct 03, 2007 4:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
dwnoon
n00b
n00b


Joined: 28 Aug 2003
Posts: 21
Location: Luton, England

PostPosted: Wed Oct 03, 2007 5:10 pm    Post subject: Reply with quote

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.
_________________
Regards,

Dave [RLU #314465]
Back to top
View user's profile Send private message
dwnoon
n00b
n00b


Joined: 28 Aug 2003
Posts: 21
Location: Luton, England

PostPosted: Tue Oct 30, 2007 7:34 pm    Post subject: Reply with quote

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.
_________________
Regards,

Dave [RLU #314465]
Back to top
View user's profile Send private message
solarflare
n00b
n00b


Joined: 25 Dec 2007
Posts: 1
Location: Finland

PostPosted: Tue Dec 25, 2007 11:39 am    Post subject: Mac mini G4 clock skew Reply with quote

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

Code:
# 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.
Back to top
View user's profile Send private message
nekromancer
Apprentice
Apprentice


Joined: 23 Feb 2004
Posts: 158
Location: Niagara, Canada

PostPosted: Sun Feb 10, 2008 4:33 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
caspar
Apprentice
Apprentice


Joined: 02 Mar 2003
Posts: 228
Location: 240 000 miles away from moon

PostPosted: Wed Mar 05, 2008 12:23 pm    Post subject: Reply with quote

For everyone who is interested
Code:
noapic ec_burst=1

did not help me.

I am now using
Code:
noapic ec_burst=1 acpi=off clock=pmtmr notsc no_timer_check

and this seems to work.
_________________
"Dream as if you'll live forever. Live as if you'll die today."
Back to top
View user's profile Send private message
Txema
l33t
l33t


Joined: 20 May 2008
Posts: 772
Location: Granada

PostPosted: Tue May 20, 2008 3:11 pm    Post subject: Reply with quote

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:

Code:
$ 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 ;)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum