NTP wijkt erg snel af

[Boudewijn]

Hoi,

Ik heb een x8dtn+ supermicro bordje in de colocatie hangen met daarop 64bits debian (squeeze) en die heeft een behoorlijk datum probleem.
Als ik ntp herstart, waarna de tijd wordt gesynched naar ntp.xs4all.nl, is alles in orde.
Dit heb ik om 20.50 gedaan... om 21.43 uur:
NTP CRITICAL: Offset -31.07144475 secs

Dat is dus in een krap uur meer dan 30 seconden. De check vergelijkt de tijd met de ntp van xs4all (waar ik eerder mee syncte...):
/usr/lib/nagios/plugins/check_ntp_time -H ntp.xs4all.nl -w 15 -c 30

Standaard Nagios NRPE checkje.
Mijn ntp.conf:

root@whitebox:/home/boudewijn# cat /etc/ntp.conf  | grep -v "^#"  | grep -v "^$"
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp.xs4all.nl iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

De driftfile wordt netjes aangemaakt en heeft als inhoud -500.000.

En de stats:

code:

root@whitebox:/var/log/ntpstats# tail loopstats
55657 50043.093 0.000000000 -500.000 0.000000119 3292.993173 6
55657 50051.110 -0.071875000 -500.000 0.025411769 3080.313057 6
55657 50113.033 -0.067544000 -500.000 0.023819805 2881.369026 6
root@whitebox:/var/log/ntpstats# tail peerstats
55657 70731.893 194.109.22.18 905a -27.983458761 0.000297554 0.000991953 2.835100212
55657 70798.894 194.109.22.18 905a -28.607799549 0.000306814 0.000981171 2.830045447
55657 70866.894 194.109.22.18 905a -29.241374758 0.000500795 0.000983223 2.831480625
55657 70932.897 194.109.22.18 905a -29.856488534 0.000360071 0.000969336 2.814319827
55657 70998.896 194.109.22.18 905a -30.471512185 0.000379202 0.000962481 2.799925496
55657 71065.893 194.109.22.18 905a -31.095846152 0.000332996 0.000966523 2.793059488
55657 71134.897 194.109.22.18 905a -31.738890212 0.000318378 0.000983457 2.804428440
55657 71202.896 194.109.22.18 905a -32.372527081 0.000348825 0.000984453 2.808581911
55657 71270.897 194.109.22.18 905a -33.006179880 0.000312839 0.000984980 2.816317681
55657 71338.894 194.109.22.18 905a -33.639794796 0.000353397 0.000985214 2.823120565

Wat kan ik hier nog aan doen? Ik snap dat ntp ermee haakt als de klok te hard gaat driften.


Hardware vervangen of downtime is de laatste optie (zoals altijd), dus een software oplossing lijkt me het handigste .

Mijn alternatief: een cronjob die leke 10 mins ntp herstart is ronduit waardeloos en smerig.

Weet iemand hier een goede truc voor?

[CyBeR]

Werkt je ntpd überhaupt wel? De init scripts van Debian draaien namelijk bij het starten eerst ntpdate.

[Boudewijn]

root@whitebox:/var/log/ntpstats# ps aux | grep ntpd
ntp      29725  0.0  0.0  38336  2168 ?        Ss   20:48   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:109

Lijkt prima te draaien:). Zowel ntp als ntpdate zijn geinstalleerd trouwens.

[joopv]

Heel vroeguh zat er een trim condensator bij de clockchip op het moederbord... (maar dat is al heel lang geleden). Maar 30 sec op 1 uur is zowat 1%, dan is er toch echt iets helemaal mis.

Als de RTC (hardware clock) niet goed is moet je het mainboard vervangen. Een andere mogelijkheid is dat de RTC interrupts gemist worden door een overbelast systeem of interrupt / driver issue.

[CyBeR]

Boudewijn schreef op woensdag 06 april 2011 @ 21:56:

root@whitebox:/var/log/ntpstats# ps aux | grep ntpd
ntp      29725  0.0  0.0  38336  2168 ?        Ss   20:48   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:109

Lijkt prima te draaien:). Zowel ntp als ntpdate zijn geinstalleerd trouwens.

Draaien, ja, maar past 'ie ook daadwerkelijk de tijd aan?

Wat zegt 'ntpq -p' trouwens?

[Boudewijn]

joopv schreef op woensdag 06 april 2011 @ 21:56:
Heel vroeguh zat er een trim condensator bij de clockchip op het moederbord... (maar dat is al heel lang geleden). Maar 30 sec op 1 uur is zowat 1%, dan is er toch echt iets helemaal mis.

True.

Als de RTC (hardware clock) niet goed is moet je het mainboard vervangen. Een andere mogelijkheid is dat de RTC interrupts gemist worden door een overbelast systeem of interrupt / driver issue.

Mja dat is echt last resort. Bak staat echt niets te doen (NFS en SSH server, met veel mem en een xeon 5506).

CyBeR schreef op woensdag 06 april 2011 @ 21:58:
[...]


Draaien, ja, maar past 'ie ook daadwerkelijk de tijd aan?

Jup, herstarten van ntp fixt de tijd... maar die is binnen een uur weer >30 secs.
ik heb 30 secs afwijking als grens gesteld binnen mijn colocated netwerk.

Wat zegt 'ntpq -p' trouwens?

root@whitebox:/var/log/ntpstats# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 auth1.xs4all.nl 193.79.237.14    2 u   64   64  377    0.423  -39911. 2784.98

[CyBeR]

Boudewijn schreef op woensdag 06 april 2011 @ 22:00:
[...]

True.

[...]

Mja dat is echt last resort. Bak staat echt niets te doen (NFS en SSH server, met veel mem en een xeon 5506).

[...]

Jup, herstarten van ntp fixt de tijd... maar die is binnen een uur weer >30 secs.
ik heb 30 secs afwijking als grens gesteld binnen mijn colocated netwerk.

Handmatig of met de init scripts? Want zoals ik al zei: de init scripts draaien ntpdate en die zet gewoon in één keer de klok goed.

root@whitebox:/var/log/ntpstats# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 auth1.xs4all.nl 193.79.237.14    2 u   64   64  377    0.423  -39911. 2784.98

Hm. Bijna 40 seconden loop je achter hier idd. De jitter is wel ook wat extreem maar dat zou dat niet mogen veroorzaken. Default kernel enzo?

Op dit moment gebruikt 'ie volgens mij trouwens die server niet, wellicht omdat de offset hoger is dan 'ie leuk vindt.

Probeer ook eens meer dan één server in je conf te zetten. Liefst drie of vijf.

[ Voor 9% gewijzigd door CyBeR op 06-04-2011 22:03 ]

[Boudewijn]

CyBeR schreef op woensdag 06 april 2011 @ 22:02:
[...]


Handmatig of met de init scripts? Want zoals ik al zei: de init scripts draaien ntpdate en die zet gewoon in één keer de klok goed.

Initscripts . Maar ik zou verwachten dat ntpd dat bij blijft houden....

Hm. Bijna 40 seconden loop je achter hier idd. De jitter is wel ook wat extreem maar dat zou dat niet mogen veroorzaken. Default kernel enzo?

Jep en hij is om 20.50 goed gezet. Colocatie is bij xs4all zelf en de andere machines (zowel een zelfde bak als de VMs op de machine ernaast) draaien prima met dezelfde settings.

pool.ntp.org gebruiken hielp trouwens niet (dat was de default, die pakt soms ook ntp.xs4all.nl).

Kernel:

root@whitebox:/var/log/ntpstats# uname -a
Linux whitebox 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux

Redelijk standaard Squeeze installatie . Ook compleet geupdate.

Op dit moment gebruikt 'ie volgens mij trouwens die server niet, wellicht omdat de offset hoger is dan 'ie leuk vindt.

True, maar toen hij begon was die tijd prima?

Probeer ook eens meer dan één server in je conf te zetten. Liefst drie of vijf.

Mja hier stond eerst 5x pool.ntp.org in zoals ik net al meldde in deze post. En dat faalde dus ook al.

[ Voor 16% gewijzigd door Boudewijn op 06-04-2011 22:07 ]

[deadinspace]

Ik heb op machines met grote clockdrift de ervaring dat openntpd het soms beter doet dan de standaard ntpd (en soms ook andersom). Je zou dus kunnen proberen of openntpd hem beter in het gareel kan houden.

Ik had trouwens op mijn nforce2 desktop bordje vroeger ook een grote clockdrift, wat later met recentere kernels verdwenen is. Ik weet nog steeds niet of die drift nou een software-probleem was, of een hardware-probleem waar recentere kernels een workaround voor hadden.

[Boudewijn]

root@whitebox:/var/log/ntpstats# ntpq  -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+vf1.bbnx.net    128.4.1.1        2 u   10   64    1  130.501  -65.250  40.637
+panoramix.linoc 193.79.237.14    2 u    8   64    1    3.829  -84.412  51.087
+ntp1.mediamatic 193.67.79.202    2 u    8   64    1    1.199  -83.926  51.081
*dione.cbane.org 69.25.96.13      2 u    6   64    1  162.386  -100.54  62.258
root@whitebox:/var/log/ntpstats# date
Thu Apr  7 00:16:59 CEST 2011
root@whitebox:/var/log/ntpstats# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 vf1.bbnx.net    128.4.1.1        2 u   63   64   77  127.188  -4098.8 2721.63
 panoramix.linoc 193.79.237.14    2 u   53   64  177    3.913  -4193.7 2769.70
 ntp1.mediamatic 193.67.79.202    2 u   60   64  177    1.249  -4128.1 2716.79
 dione.cbane.org 69.25.96.13      2 u   30   64  377  163.126  -4404.6 2798.20
root@whitebox:/var/log/ntpstats# date
Thu Apr  7 00:25:12 CEST 2011
root@whitebox:/var/log/ntpstats# 

Dit is is met :

code:

server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic

als NTPs


@deadinspace : interesting. Ga ik morgen eens proberen. DOe dat liever niet 's nachts .


Deze machine serveert trouwens NFS aan een naastgelegen machine over dezelfde NIC als waarop hij aan het internet hangt. Kan dit wat uitmaken? De NIC wordt lang niet dichtgetrokken trouwens.

[ Voor 5% gewijzigd door Boudewijn op 07-04-2011 00:28 ]

[CyBeR]

Boudewijn schreef op donderdag 07 april 2011 @ 00:27:

root@whitebox:/var/log/ntpstats# ntpq  -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+vf1.bbnx.net    128.4.1.1        2 u   10   64    1  130.501  -65.250  40.637
+panoramix.linoc 193.79.237.14    2 u    8   64    1    3.829  -84.412  51.087
+ntp1.mediamatic 193.67.79.202    2 u    8   64    1    1.199  -83.926  51.081
*dione.cbane.org 69.25.96.13      2 u    6   64    1  162.386  -100.54  62.258
root@whitebox:/var/log/ntpstats# date
Thu Apr  7 00:16:59 CEST 2011
root@whitebox:/var/log/ntpstats# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 vf1.bbnx.net    128.4.1.1        2 u   63   64   77  127.188  -4098.8 2721.63
 panoramix.linoc 193.79.237.14    2 u   53   64  177    3.913  -4193.7 2769.70
 ntp1.mediamatic 193.67.79.202    2 u   60   64  177    1.249  -4128.1 2716.79
 dione.cbane.org 69.25.96.13      2 u   30   64  377  163.126  -4404.6 2798.20
root@whitebox:/var/log/ntpstats# date
Thu Apr  7 00:25:12 CEST 2011
root@whitebox:/var/log/ntpstats# 

Dit is is met :

code:

server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic

als NTPs

Grappig. Je selecteert uit de global pool en je krijgt een van mijn NTPds erbij

Deze machine serveert trouwens NFS aan een naastgelegen machine over dezelfde NIC als waarop hij aan het internet hangt. Kan dit wat uitmaken? De NIC wordt lang niet dichtgetrokken trouwens.

Nah. Dat zou hoogstens een beetje jitter en mischien af en toe een verloren packet veroorzaken.

[Boudewijn]

Maar goed, de jitter blijft butt en ook nu is de tijd al lang keihard aan het voorlopen.

[joopv]

workaround: Als je op een andere lokale machine (hetzelfde lokale subnet) een ntp server draait kun je zonder gewetensbezwaren iedere minuut of nog sneller ntp synchroniseren tegen die machine.

[!null]

Wanneer de machine zonder NTP draait, loopt hij dan ook vrij snel (na een dag of 2 ofzo) uit sync?

Wel vaag, behoorlijke delays naar de helft van de servers (de andere helft prima) en dan voor allemaal hoge jitter en offset.

Als je hem nou eens met -g runt?

[ Voor 46% gewijzigd door !null op 07-04-2011 08:33 ]

[DataGhost]

Eh nee, deze optie deed iets anders dan ik dacht.

[ Voor 75% gewijzigd door DataGhost op 07-04-2011 08:46 ]

[AtleX]

Heb je iets van clock throttling/EIST/Speedstep/PowerNow aanstaan? Dan gaat NTPD hopeloos uit de pas lopen, ik heb ook een keer de fout gemaakt een NTP-server weg te hangen zonder EIST uit te zetten, toen ik dus vrolijk nog een keer naar het datacentre.

[ Voor 40% gewijzigd door AtleX op 07-04-2011 08:47 ]

[Verwijderd]

nadat je de tijd ophaalde, hoef je dan ook de hardware clock ook niet op die tijd in te stellen?

hwclock --systohc

dagelijks loopt in /etc/cron.daily/ een script ntpdate met een ntpdate naar een landelijke pool.ntp.org, kan me voorstellen dat dit ook kan in /etc/cron.hourly/ (Ubuntu)
plaatselijke tijdservers en zo meer: http://support.ntp.org/bin/view/Servers/WebHome
voor Nederland: nl.pool.ntp.org

code:

server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org
server 3.nl.pool.ntp.org

moet het iets nauwkeuriger: http://ntp.linocomm.net/index.nl.htm met deze beperking:
Hoe maak ik verbinding met jullie tijdservers?
Het is niet de bedoeling rechtstreeks contact te maken, tenzij je een beheerder bent van een Stratum 3 server die zelf weer een groot aantal cliënten heeft.

voor België: be.pool.ntp.org

code:

server 1.be.pool.ntp.org
server 3.europe.pool.ntp.org
server 2.europe.pool.ntp.org

moet het iets nauwkeuriger: http://www.astro.oma.be/D1/TIME/ntp_nl.php

[Boudewijn]

!null schreef op donderdag 07 april 2011 @ 08:31:
Wanneer de machine zonder NTP draait, loopt hij dan ook vrij snel (na een dag of 2 ofzo) uit sync?

Wel vaag, behoorlijke delays naar de helft van de servers (de andere helft prima) en dan voor allemaal hoge jitter en offset.

Als je hem nou eens met -g runt?

Hij loopt net zo hard eruit zonder ntp. Net getest.

workaround: Als je op een andere lokale machine (hetzelfde lokale subnet) een ntp server draait kun je zonder gewetensbezwaren iedere minuut of nog sneller ntp synchroniseren tegen die machine.

Waarom kan dat niet met een remote server?

Heb je iets van clock throttling/EIST/Speedstep/PowerNow aanstaan? Dan gaat NTPD hopeloos uit de pas lopen, ik heb ook een keer de fout gemaakt een NTP-server weg te hangen zonder EIST uit te zetten, toen ik dus vrolijk nog een keer naar het datacentre.

Afaik niet. Ding is gewoon productiebak dus continu volle bak.

Verwijderd schreef op donderdag 07 april 2011 @ 10:47:
nadat je de tijd ophaalde, hoef je dan ook de hardware clock ook niet op die tijd in te stellen?

hwclock --systohc

dagelijks loopt in /etc/cron.daily/ een script ntpdate met een ntpdate naar een landelijke pool.ntp.org, kan me voorstellen dat dit ook kan in /etc/cron.hourly/ (Ubuntu)

Mja in een uur loopt hij al een minuut voor . ik heb hem nu elke 10 minuten staan...

Het is niet de bedoeling rechtstreeks contact te maken, tenzij je een beheerder bent van een Stratum 3 server die zelf weer een groot aantal cliënten heeft.

Los van de definitie van 'een groot aantal' denk ik niet dat het de bedoeling is dat ik het ga gebruiken op die manier.

[Verwijderd]

Heel uitgebreid onderwerp over tijd en hardware klok en computers en hun OS: http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-sw-clocks.htm.

[ipsec]

Draai je toevallig op vmware/xen?

Wij hadden te maken met dezelfde issue op voornamelijk de Xen machines, dit hebben wij opgelost door het volgende te doen:

Logon to the Linux Virtual Machine as root and enter the command:

echo 1 > /proc/sys/xen/independent_wallclock

To make the same persist across reboots, edit the /etc/sysctl.conf file and add the following lines:

# Set independent wall clock time
xen.independent_wallclock=1

bron: http://xtravirt.com/disab...tion-multiple-hypervisors

[deadlock2k]

Voor VMware moet er in de guest -clock=pit in de bootloader staan in dat geval

[ipsec]

Ja, maar met VMWare kan je het ook in je management tool nog uitzetten. Niet dat dat altijd goed gaat, daar niet van...

[Verwijderd]

Mocht het klok probleem blijven bestaan: Toevallig geen NAS staan, de meeste hebben NTP server functie en kunnen extern synchroniseren. Vermijdt je eventueel problemen met te veel extern synchroniseren.
De bovenvermelde beperking (alleen als je Stratum 3 server die zelf weer een groot aantal cliënten heeft) geldt enkel voor de linocomm tijdserver en niet voor de astro.oma.be

[Boudewijn]

Verwijderd schreef op zaterdag 09 april 2011 @ 08:33:
Heel uitgebreid onderwerp over tijd en hardware klok en computers en hun OS: http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-sw-clocks.htm.

Interessante lectuur, die ga ik eens doorlezen .

SuperKevin schreef op dinsdag 12 april 2011 @ 13:34:
Draai je toevallig op vmware/xen?

In de startpost staat dat ik geen hw wil vervangen, het is dus een fysieke machine.

Verwijderd schreef op woensdag 13 april 2011 @ 17:05:
Mocht het klok probleem blijven bestaan: Toevallig geen NAS staan, de meeste hebben NTP server functie en kunnen extern synchroniseren. Vermijdt je eventueel problemen met te veel extern synchroniseren.
De bovenvermelde beperking (alleen als je Stratum 3 server die zelf weer een groot aantal cliënten heeft) geldt enkel voor de linocomm tijdserver en niet voor de astro.oma.be

Nee geen NTP'end nasje staan. ik zie ook niet in wat hier de oplossing zou zijn daarmee?

Teveel extern synchen: ik doe het nu elke 10 minuten... dat lijkt me geen misbruik:).
Overige NTPs: Tsja deze hardware hangt bij xs4all in het rack, de xs4all NTP zal denk ik het dichtste bij zijn .

[endeavor334]

Als ik dit document bekijk dat is dit wel interessante info:

High Performance Event Timer
Select Enabled to activate the High Performance Event Timer (HPET) that produces
periodic interrupts at a much higher frequency than a Real-time Clock (RTC) does in
synchronizing multimedia streams, providing smooth playback and reducing the de-
pendency on other timestamp calculation devices, such as an x86 RDTSC Instruc-
tion embedded in the CPU. The High Performance Event Timer is used to replace
the 8254 Programmable Interval Timer. The options are Enabled and Disabled.

Dat zou e.e.a kunnen verklaren.

Ik weet dat VMware server toen der tijd ook problemen had met de rtc. dit moest ik in de sysctl.conf zetten:

code:

#Performance tunes
#http://jaysonrowe.wordpress.com/2008/01/04/vmware-server-tipsntricks/
vm.swappiness = 0
vm.overcommit_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 1000
dev.rtc.max-user-freq = 1024

Met name dev.rtc.max-user-freq = 1024 deed e.e.a.

[ Voor 24% gewijzigd door endeavor334 op 14-04-2011 07:42 ]

[ipsec]

Boudewijn schreef op woensdag 13 april 2011 @ 18:55:

[...]
In de startpost staat dat ik geen hw wil vervangen, het is dus een fysieke machine.
[...]

De machinenaam "Whitebox" deed vermoeden dat je op de machine virtualisatie had toegepast, om misschien wat minder afhankelijk van hardware te zijn...

Overigens heb ik het niet gehad over hardware vervangen


Het zou overigens goed de HPET kunnen zijn die de hwclock in de war stuurt....

[tech-no-logical]

ik heb zelf een bordje dat per uur 168 of 169 seconden drift (de drift is wel stabiel). zelfs openntpd kon daar (ruim een jaar geleden getest) niets mee. mijn oplossing :

58  *  *  *  *  rdate -ncv ntp.xs4all.nl | logger -t NTP

in crontab. ranzig, maar voor mij de enige oplossing zonder hardware te vervangen. werkte alleen als je geen processen draait die gaan stuiteren van elk uur een jump van 169 seconden...

[Boudewijn]

tech-no-logical schreef op donderdag 14 april 2011 @ 10:55:
ik heb zelf een bordje dat per uur 168 of 169 seconden drift (de drift is wel stabiel). zelfs openntpd kon daar (ruim een jaar geleden getest) niets mee. mijn oplossing :

58  *  *  *  *  rdate -ncv ntp.xs4all.nl | logger -t NTP

in crontab. ranzig, maar voor mij de enige oplossing zonder hardware te vervangen. werkte alleen als je geen processen draait die gaan stuiteren van elk uur een jump van 169 seconden...

Ik doe ietsdergelijks elke 10 minuten.

SuperKevin schreef op donderdag 14 april 2011 @ 10:45:
De machinenaam "Whitebox" deed vermoeden dat je op de machine virtualisatie had toegepast, om misschien wat minder afhankelijk van hardware te zijn...

Aannames en vergissingen . Nee de bak is zo fysiek als maar zjin kan.

Overigens heb ik het niet gehad over hardware vervangen

Ik wel en dat is een indicatie dat het harwdare is.

Het zou overigens goed de HPET kunnen zijn die de hwclock in de war stuurt....

Daar lijkt het wel op. Zullen we binnenkort eens uitzetten.

[Wirehead]

Ik heb ook iets gelijkaardig gehad met een openfiler-box die ik thuis gebruik voor VM testen. Niks mis met de HW, op linux echter wat drift met jitter. Het volgende boot-argument bracht de oplossing:
clocksource=hpet no_timer_check

En dan in ntp.conf het volgende:
server xxx.xxx.xxx.xxx(=mijn interne NTP) prefer minpoll 4 maxpoll 6
server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift

Gaat op die manier sneller pollen, maar zorgt ervoor dat je een accurate drift-file krijgt. Ondertussen loopt dit perfect


remote refid st t when poll reach delay offset jitter
==============================================================================
*xxx.xxx.xxx.xxx 85.88.55.5 3 u 16 64 377 0.154 -0.117 0.013

[endeavor334]

Ik heb hier nog e.e.a gevonden over clock driften.

via

 cat /sys/devices/system/clocksource/clocksource0/current_clocksource

kun je kijken welke clock er op dit moment actief is.

Bij mij:

~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
hpet

en wat er beschikbaar is:

~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
hpet acpi_pm 

Dit levert ook wel interessante info op ,gevonden op dit forum

~$ cat /proc/driver/rtc 
rtc_time	: 22:18:29
rtc_date	: 2011-04-15
alrm_time	: 01:23:32
alrm_date	: ****-**-**
alarm_IRQ	: no
alrm_pending	: no
24hr		: yes
periodic_IRQ	: no
update_IRQ	: no
HPET_emulated	: yes
BCD		: yes
DST_enable	: no
periodic_freq	: 1024
batt_status	: okay

Andere interessante info:
http://www.islief.com/mediawiki/index.php/Linux_Time
http://log.or.cz/?p=80

[ Voor 101% gewijzigd door endeavor334 op 15-04-2011 22:40 ]

[brambo123]

Je mag altijd mijn ntp server gebruiken: ntp0.mtsgrit.nl
Die gebruikt dus onder andere linocomm servers

[Boudewijn]

SuperKevin schreef op donderdag 14 april 2011 @ 10:45:
Het zou overigens goed de HPET kunnen zijn die de hwclock in de war stuurt....

Vandaag na een reboot gefixed, en het werkt weer als een trein .

[Boudewijn]

Een laatste update, we zijn bijna een week verder... niets aan het handje. Ding draait als een trein.

De HPET timer uitschakelen was de fix.