View previous topic :: View next topic |
Author |
Message |
Yankee Tux's lil' helper
Joined: 25 Jul 2003 Posts: 77 Location: Germany
|
Posted: Sun Jun 03, 2007 1:33 pm Post subject: [SOLVED] Clock skew |
|
|
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 |
|
|
jlh Tux's lil' helper
Joined: 06 May 2007 Posts: 145 Location: Switzerland::Zürich
|
Posted: Sun Jun 03, 2007 4:23 pm Post subject: |
|
|
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 |
|
|
Yankee Tux's lil' helper
Joined: 25 Jul 2003 Posts: 77 Location: Germany
|
Posted: Sun Jun 03, 2007 4:42 pm Post subject: |
|
|
This is an x86 architecture running version 2.6.20-r8 of gentoo-sources. |
|
Back to top |
|
|
beda42 n00b
Joined: 08 Jun 2007 Posts: 3
|
Posted: Fri Jun 08, 2007 6:57 am Post subject: progress |
|
|
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 |
|
|
Yankee Tux's lil' helper
Joined: 25 Jul 2003 Posts: 77 Location: Germany
|
Posted: Fri Jun 08, 2007 7:07 am Post subject: |
|
|
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 |
|
|
albright Advocate
Joined: 16 Nov 2003 Posts: 2588 Location: Near Toronto
|
Posted: Fri Jun 08, 2007 12:45 pm Post subject: |
|
|
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 |
|
|
batistuta Veteran
Joined: 29 Jul 2005 Posts: 1384 Location: Aachen
|
Posted: Fri Jun 08, 2007 2:10 pm Post subject: |
|
|
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
set date accordingly
Code: | date MMDDhhmm[[CC]YY][.ss] |
set the hw clock
Code: | hwclock --utc --systohc |
adjust your clock
remove file
set the hw clock
Code: | hwclock --utc --systohc |
And report back results |
|
Back to top |
|
|
beda42 n00b
Joined: 08 Jun 2007 Posts: 3
|
Posted: Thu Jun 21, 2007 11:42 am Post subject: new kernel and some options fixed it |
|
|
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 |
|
|
beda42 n00b
Joined: 08 Jun 2007 Posts: 3
|
Posted: Thu Jun 21, 2007 11:45 am Post subject: ..more info |
|
|
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 |
|
|
Yankee Tux's lil' helper
Joined: 25 Jul 2003 Posts: 77 Location: Germany
|
Posted: Sun Jun 24, 2007 8:26 am Post subject: |
|
|
Thanks for your info beda! Using gentoo sources 2.6.21-r3 and adding noapic to boot options helped me too. |
|
Back to top |
|
|
ozbird Apprentice
Joined: 21 Oct 2003 Posts: 185
|
Posted: Wed Jun 27, 2007 2:15 am Post subject: gentoo 2.6.21-r3 and 300Hz kernel timer breaks NTP? |
|
|
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 |
|
|
OldTango l33t
Joined: 21 Feb 2004 Posts: 718
|
Posted: Mon Jul 02, 2007 8:51 pm Post subject: |
|
|
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
set date accordingly
Code: | date MMDDhhmm[[CC]YY][.ss] |
set the hw clock
Code: | hwclock --utc --systohc |
adjust your clock
remove file
set the hw clock
Code: | hwclock --utc --systohc |
And report back results | 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............................... |
|
Back to top |
|
|
J_L n00b
Joined: 11 Sep 2006 Posts: 68 Location: Gothenburg
|
Posted: Tue Oct 02, 2007 7:22 pm Post subject: |
|
|
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 |
|
|
Yankee Tux's lil' helper
Joined: 25 Jul 2003 Posts: 77 Location: Germany
|
Posted: Tue Oct 02, 2007 7:26 pm Post subject: |
|
|
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 |
|
|
J_L n00b
Joined: 11 Sep 2006 Posts: 68 Location: Gothenburg
|
Posted: Tue Oct 02, 2007 7:30 pm Post subject: |
|
|
Yes, using 2.6.22-gentoo-r8 with noapic |
|
Back to top |
|
|
geoffp n00b
Joined: 10 Oct 2004 Posts: 47
|
Posted: Wed Oct 03, 2007 4:14 am Post subject: |
|
|
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 |
|
|
dwnoon n00b
Joined: 28 Aug 2003 Posts: 21 Location: Luton, England
|
Posted: Wed Oct 03, 2007 5:10 pm Post subject: |
|
|
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 |
|
|
dwnoon n00b
Joined: 28 Aug 2003 Posts: 21 Location: Luton, England
|
Posted: Tue Oct 30, 2007 7:34 pm Post subject: |
|
|
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 |
|
|
solarflare n00b
Joined: 25 Dec 2007 Posts: 1 Location: Finland
|
Posted: Tue Dec 25, 2007 11:39 am Post subject: Mac mini G4 clock skew |
|
|
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 |
|
|
nekromancer Apprentice
Joined: 23 Feb 2004 Posts: 158 Location: Niagara, Canada
|
Posted: Sun Feb 10, 2008 4:33 pm Post subject: |
|
|
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 |
|
|
caspar Apprentice
Joined: 02 Mar 2003 Posts: 228 Location: 240 000 miles away from moon
|
Posted: Wed Mar 05, 2008 12:23 pm Post subject: |
|
|
For everyone who is interested
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 |
|
|
Txema l33t
Joined: 20 May 2008 Posts: 772 Location: Granada
|
Posted: Tue May 20, 2008 3:11 pm Post subject: |
|
|
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 |
|
|
|