[Linux] tijd loopt te langzaam

[Tead]

Ik heb hier een HP T5000 thin client staan waar Debian 4.0 Etch op draai. Het valt mij op dat de tijd te langzaam loopt. per 60 seconde mist hij ongeveer 1 seconde. Nu dacht ik dit met ntp te voorkomen, maar deze werkt niet.

ik heb ntp en ntpd geinstalleerd en deze gestart:

code:

server:/home/user# /etc/init.d/ntp start
Starting NTP server: ntpd.
server:/home/user# ps waux | grep ntpd
ntp      25372  0.2  0.6   4052  1312 ?        Ss   23:44   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 105:104 -g

De config file ziet er als volgt uit:

code:

driftfile /var/lib/ntp/ntp.drift

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

In ntp.drift staat 0.000. Het helpt niet als ik dit bestand uit de config haal en/of bestand verwijder. De adjtime file heb ik al eens verwijderd. Als ik de ntpd kill en ntpdate ntp.xs4all.nl doe corrigeert hij de tijd wel. Volgend screenshot is te zien wat ik zie als ik een strace doe op de ntpd:


(misschien kan iemand hier iets mee)

nog het laatste waar ik naar gekeken heb, de peerstats in de log dir:

code:

54329 6.761 192.87.106.2 9034 3526.405139407 0.002446888 0.005246949 2.488586572
54329 17.778 192.33.214.57 9054 3528.583100837 0.018322822 0.002539269 1.700236636
54329 32.783 192.36.143.150 9054 3530.718121205 0.024135606 0.001941164 2.992291452
54329 49.810 80.239.2.146 9034 3530.225799568 0.052684341 0.002885459 2.453121463

laat dus goed zien dat de tijd out of sync loopt.

Wie o wie heeft de gouden tip om dit probleem op te lossen.

[deadinspace]

Tead schreef op maandag 03 september 2007 @ 00:23:
Ik heb hier een HP T5000 thin client staan waar Debian 4.0 Etch op draai. Het valt mij op dat de tijd te langzaam loopt. per 60 seconde mist hij ongeveer 1 seconde.

Dat is nogal veel; het duidt op een probleem met de system clock, of de aansturing (vanuit software) daarvan. Treedt die afwijking ook op in andere OSsen, of bijvoorbeeld in de BIOS?

Je zou ook kunnen zoeken of anderen dit probleem tegengekomen zijn met dezelfde hardware.

Nu dacht ik dit met ntp te voorkomen, maar deze werkt niet.

Hoe lang heb je gewacht om te kijken of het helpt? Het kan zijn dat ntpd even nodig heeft om te leren wat de afwijking van je clock is. Het kan ook zijn dat de drift te groot is, -1.5% is ook niet niks.

Je zou ook nog openntpd in plaats van ntpd kunnen proberen, deze is volgensmij iets aggressiever.

Volgend screenshot is te zien wat ik zie als ik een strace doe op de ntpd:

Je kan het beter als tekst in je post zetten dan als screenshot. Op die manier kunnen mensen eruit copy/pasten of relevante stukken quoten. Bovendien blijft die tekst dan tot in de eeuwigheid in het topic behouden, wat handiger kan zijn voor mensen die later je topic via de search vinden

[Verwijderd]

Het duurt inderdaad een tijdje voordat ntp daadwerkelijk je klok gaat aanpassen, en dan volgens mij ook nog vrij langzaam zodat er geen grote tijdsprongen optreden.

Met `ntpq` kan je de status van ntpd uitlezen. Je krijgt dan een prompt, typ bijv `peers` en `ass`, je ziet dan met welke servers je synchroniseert en wat meer info. Misschien kan je dan zien wat er mis is.

[blaataaps]

Met adjtimex kun je de snelheid aanpassen, misschien helpt dat.

[Tead]

Ik heb de pool servers uit de config gehaald en nu alleen ntp.xs4all.nl er ingezet. Deze draait nu 1 dag en het verschil is nu 15 minuten. Maar als ik dit een week laat draaien (wat ik het verleden al gedaan heb) loopt dat verschil alleen maar op.

Dit is te zien als ik ntpq doe met de commando's "peers" en "ass":

code:

ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 auth1.xs4all.nl 194.109.23.210   3 u   47   64  377    3.029  868807. 2461.51
ntpq> ass

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 55592  9014   yes   yes  none    reject   reachable  1

Bij offset staat 868807 milliseconde, dat is ongeveer ook 15 minuten. Bij ass staat condition op reject. Geen idee wat dat betekend, maar vast niet veel goeds ...

quote: http://www.linuxcommand.org/man_pages/adjtimex8.html

For a standalone or intermittently connected machine, where it’s not possible to run ntpd, you may use adjtimex instead to correct the system clock for systematic drift.

Eerst ntp goed aan de praat te krijgen, lukt dat niet wordt dit het alternatief.

Verder nog ideeën?

[Verwijderd]

Tsja, dan wordt het lastig .. :-) Die reject is inderdaad niet goed; er zou 'sys.peer' moeten staan. Ik denk dat er twee opties zijn: of je offset is te groot, ntp past dan de tijd niet aan; ik dacht alleen dat de maximale offset een uur is dus dat zou bij jou dan niet opgaan maar misschien is het een instelling en kan je 's kijken? Of je wacht niet lang genoeg: ntp doet er een tijd over om een ntp-server te kiezen waarvan hij de tijd gaat overnemen, dus laat 'm rustig 's een paar uur draaien als je dat al nog niet gedaan had.

Er is ook een commandline optie om het debuglevel op te schroeven, dat zou je ook 's kunnen proberen en kijken wat er nou precies gebeurt.

[Verwijderd]

Ik kom dit probleem veel tegen binnen virtual machines, en dat komt door het volgende (simpel gezegd).

Linux houd de tijd bij aan de hand van de te verwachten klok tiks. Bij een cpu van 1 Ghertz wacht de kernel 1000 klock ticks af voordat hij de tijd 1 sec vooruit zet. Als je kernel dus maar de helft van de verwachte klock ticks krijgt gaat de tijd in eens half zo snel. Binnen de virtualisatie komt dit probleem voor doordat de kernel ziet welke cpu je hebt, maar niet alle clock ticks krijgt (immers er zijn meerder virtual machines die ook clock ticks nodig zijn om hun taak uit te voeren).

Ik los dit probleem gedeeltelijk op door openntpd en ntpdate te instaleren. De ntp toold ie jij gebruikt vind ik vaak ook niet echt fijn werken. Met de volgende lijnen code zou je probleem werkbaar moeten zijn.


(uit men hoofd, als het niet werkt zeg het dan even. Dan kijk het eventjes naar)

code:

apt-get remove ntp --purge
apt-get install openntpd ntpdate
/etc/init.d/openntpd stop
ntpdate ntp.xs4all.nl
/etc/init.d/openntpd start

Laat ff weten wat je resultaat is.

[ Voor 35% gewijzigd door Verwijderd op 04-09-2007 10:20 ]

[killercow]

Is je werk niet gewoon oer saai waardoor het *lijkt* dat je tijd langzaam gaat?

[VisionMaster]

herhaal de ntpdate ntp.xs4all.nl een keertje, want het rapporteert op de stdout wat je huidige offset is. NTP zal meestal niet in keer je tijd goedknallen. Dat doet hij tot op zeker hoogte. Is je verschil te groot, dan kan de daemon simpelweg weigeren die update te doen, dus regelmatig ntpdate draaien of met aggressievere instellingen mee geven is een optie.

[Verwijderd]

VisionMaster schreef op dinsdag 04 september 2007 @ 12:31:
herhaal de ntpdate ntp.xs4all.nl een keertje, want het rapporteert op de stdout wat je huidige offset is. NTP zal meestal niet in keer je tijd goedknallen. Dat doet hij tot op zeker hoogte. Is je verschil te groot, dan kan de daemon simpelweg weigeren die update te doen, dus regelmatig ntpdate draaien of met aggressievere instellingen mee geven is een optie.

Volgens mij doet hij die update wel alleen update hij de tijd heel geleidelijk zodat de draaiende applicaties niet in de war raken.

[VisionMaster]

Verwijderd schreef op dinsdag 04 september 2007 @ 13:07:
[...]


Volgens mij doet hij die update wel alleen update hij de tijd heel geleidelijk zodat de draaiende applicaties niet in de war raken.

Klopt, dat doetie ook precies om die reden
In ieder geval als je de daemon gebruikt. Maar met VMs kan die inhaalslag niet snel genoeg gemaakt worden. Als je zelf ntpdate draait (een paar keer) dan schopt hij de klok veel harder in de goede richting. Je kan dit allemaal in stellen in de ntp.conf file.

[Tead]

Verwijderd schreef op dinsdag 04 september 2007 @ 10:19:
(uit men hoofd, als het niet werkt zeg het dan even. Dan kijk het eventjes naar)

code:

apt-get remove ntp --purge
apt-get install openntpd ntpdate
/etc/init.d/openntpd stop
ntpdate ntp.xs4all.nl
/etc/init.d/openntpd start

Laat ff weten wat je resultaat is.

Net 3 sec geleden uitgevoerd, werkt wel. Kan je morgen rond deze tijd vertellen of hij nog synchroon loopt

killercow schreef op dinsdag 04 september 2007 @ 12:07:
Is je werk niet gewoon oer saai waardoor het *lijkt* dat je tijd langzaam gaat?

Mijn werk is alles behalve saai. Maar ik ga altijd te laat weg omdat die klok altijd minimaal een uur achter loopt

[Verwijderd]

Net 3 sec geleden uitgevoerd, werkt wel. Kan je morgen rond deze tijd vertellen of hij nog synchroon loopt

Ik ben benieuwd. Of je unit nog steeds niet goed op tijd loopt

Mocht het niet werken, zou je er voor kunnen kiezen om de openntpd servers weer te verwijderen. En door middel van een cronjob elke minuut/kwartier/uur(?) ntpdate uit te voeren. Het is niet meest nette oplossing. Maar ik verwacht wel dat de tijd daardoor goed zou moeten blijven lopen.

[VisionMaster]

Er is een fix voor trouwens he

AFAIK was het een kernel optie die je moet zetten. Wij hadden het probleem hier ook toen we van RHEL3 naar RHEL4 gingen, die interrupts waren van 100x per tijdseenheid naar 1000x per weet-ik-veel-wat-voor-tijds-eenheid. Dat kan je dus aanpassen en dan heb je die aggresieve drift niet meer.

[Tead]

na ongeveer 24 uur de openntpd gedraaid te hebben is het verschil weer opgelopen tot 12 minuten.

VisionMaster schreef op woensdag 05 september 2007 @ 19:21:
Er is een fix voor trouwens he

AFAIK was het een kernel optie die je moet zetten. Wij hadden het probleem hier ook toen we van RHEL3 naar RHEL4 gingen, die interrupts waren van 100x per tijdseenheid naar 1000x per weet-ik-veel-wat-voor-tijds-eenheid. Dat kan je dus aanpassen en dan heb je die aggresieve drift niet meer.

Zou jij mij kunnen uitleggen hoe ik dit in de kernel kan gooien?

[VisionMaster]

Tead schreef op donderdag 06 september 2007 @ 00:36:
na ongeveer 24 uur de openntpd gedraaid te hebben is het verschil weer opgelopen tot 12 minuten.
[...]
Zou jij mij kunnen uitleggen hoe ik dit in de kernel kan gooien?

Hier worden allerlei problemen met de tijd uitgelegd:
http://www.vmware.com/pdf/vmware_timekeeping.pdf

Niet directe oplossing met ntpd:
Voeg toe in de /etc/ntp.conf de volgende regel:

code:

tinker panic 0

De 0 waarde geeft aan dat het alle mogelijke offsets accepteerd en zou de tijd in 1x op de goede tijd kunnen schoppen. Maar goed, dan heb je nog steeds je aggressieve drift.

Nog een mogelijke oplossing in een vmware omgeving:
http://vmblog.com/archive...ms-with-the-guest-os.aspx

Als je een linux 2.6 kernel gebruikt in je Guest, dan kan je in Grub instellen dat je kernel een bepaalde interupt snelheid moet bijhouden. Ik moet nog effe zoeken in onze interne Wiki's


edit:
De oplossing is een kernel parameter opgeven in de bootloader (grub):
kernel /vmlinuz-2.6.9-34.EL ro root=/dev/VolGroup00/LogVol00 clock=pit

KB van VMWare: http://kb.vmware.com/self...displayKC&externalId=1420

[ Voor 11% gewijzigd door VisionMaster op 06-09-2007 09:23 ]

[Jungian]

Microsoft heeft hier ook een interessant artikel over geschreven.

[Tead]

VisionMaster schreef op donderdag 06 september 2007 @ 09:20:
Voeg toe in de /etc/ntp.conf de volgende regel:

code:

tinker panic 0

deze heb ik togevoegd aan de ntpd.conf van openntpd ...

De oplossing is een kernel parameter opgeven in de bootloader (grub):
kernel /vmlinuz-2.6.9-34.EL ro root=/dev/VolGroup00/LogVol00 clock=pit

... en deze heb ik toegevoegd aan mijn grub boot loader. Na een reboot en 3 uur later loopt de tijd nog steeds goed

Ik heb even gekeken met ntpdate:

code:

adjust time server 194.109.22.18 offset -0.197542 sec
adjust time server 194.109.22.18 offset -0.200299 sec
adjust time server 194.109.22.18 offset -0.195941 sec
adjust time server 194.109.22.18 offset -0.191833 sec

deze schommelt dus tussen -0.2 en 0.2, een offset waar ik niet wakker van lig.

Bedankt allen voor het meedenken en VisionMaster voor de uiteindelijke oplossing.

[VisionMaster]

Tead schreef op donderdag 06 september 2007 @ 21:03:
[...]

deze heb ik togevoegd aan de ntpd.conf van openntpd ...

[...]

... en deze heb ik toegevoegd aan mijn grub boot loader. Na een reboot en 3 uur later loopt de tijd nog steeds goed

Ik heb even gekeken met ntpdate:

code:

adjust time server 194.109.22.18 offset -0.197542 sec
adjust time server 194.109.22.18 offset -0.200299 sec
adjust time server 194.109.22.18 offset -0.195941 sec
adjust time server 194.109.22.18 offset -0.191833 sec

deze schommelt dus tussen -0.2 en 0.2, een offset waar ik niet wakker van lig.

Bedankt allen voor het meedenken en VisionMaster voor de uiteindelijke oplossing.

Mijn collega op het lab had dit als eerste ontdekt een jaar terug, dus eerlijkheid gebiedt me te zeggen dat ik het slechts onthouden had dat hij dat al eens gefixt had. Hij had het hier intern rond gemaild aan ons clubje Grid computing dudes.