NTPd stabiliseert niet *

[raswic]

Ik heb al tijden een ntp server draaien en dit ging tot nu toe goed. Enkele dagen geleden bekeek ik de output van ntpq -p eens en toen vond ik het toch wat vreemd

Hieronder de output

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+auth1.xs4all.nl 131.188.3.220    2 u   28   64   37    7.982  -1277.2 340.496
*auth2.xs4all.nl 193.67.79.202    2 u   34   64   37    7.984  -1258.2 335.749

In eerste instantie niet zo vreemd als je de deamon net opstart maar deze draaide toch al een tijdje. De logfile leerde mij dat ongeveer om het half uur de klok enkele seconden werdt gecorrigeerd en dit al de gehele week! Een week geleden liep de pc niet minuten verkeerd.

de ntp.conf file ziet er als volgt uit

code:

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 auth1.xs4all.nl
server auth2.xs4all.nl

Op zich niets vreemd want mijn tweede server draait met een identieke configuratie. Wel op een andere lokatie, maar dat moet niets uitmaken.
Beide zijn debian systemen verbonden met een adsl-verbinding van xs4all.

Aangezien ik dit probleem niet zelf heb kunnen oplossen en ik via de search en google oplossing heb kunnen vinden vraag ik het hier even.

Wie weet raad?

[Wirehead]

Die jitter lijkt me op zich wel redelijk hoog.

Wat ik me ook nog ergens kan herinneren is als het verschil in tijd met de NTP server te hoog is, deze gewoon weigert de tijd in te stellen. (offset dan)

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp0.nl.uu.net  .GPS.            1 u  384 1024  377   23.697   -1.057   0.926
-ntp1.nl.uu.net  .GPS.            1 u  121 1024  377   21.556   -2.084  11.077
-hora.cs.tu-berl .PPS.            1 u 1290 1024  376   45.403   -1.638   1.151
-sombrero.cs.tu- .PPS.            1 u  297 1024  177   45.520    0.669  22.787
-192.53.103.103  .PTB.            1 u  371 1024  377   49.931    4.443   2.098
-ntp2.ptb.de     .PTB.            1 u  269 1024  377   78.978   24.871  19.835
+ntp1.oma.be     193.190.230.71   2 u  301 1024  377   12.812   -0.789   0.378
+ntp.charon.tele 193.79.237.14    2 u  324 1024  377   11.821   -0.815   0.151
-holem.belnet.be 193.190.198.43   2 u  345 1024  377   12.940    1.560   1.124
 LOCAL(0)        LOCAL(0)         3 l   13   64  377    0.000    0.000   0.001
 192.168.0.255   .BCST.          16 u    -   64    0    0.000    0.000 4000.00

Zo ziet het er bij mij uit

[ Voor 73% gewijzigd door Wirehead op 29-12-2005 21:37 ]

[raswic]

Die grens ligt hoger dan de waardes die ik heb en als ik begin met een offset van ongeveer 100, dan loopt het alleen maar op. Niet af.

Dat is juist het raadsel wat ik niet begrijp.

[Wirehead]

Je hebt toch ntp-refclock geïnstalleerd i.p.v. ntp-simple ?

[raswic]

Nee, ntp-simple. Ik heb zelf geen ontvanger, Ik synchroniseer via internet

[BoAC]

Heb je laatst een nieuwe kernel geinstalleerd?
Misschien dat je systeemklok daardoor teveel drift..

[raswic]

Ik heb enkele maanden terug een nieuwe kernel geinstalleerd dus het zou er iets mee te maken kunnen hebben. Het probleem is mij nu pas opgevallen.

Als het aan mijn kernel ligt, wat kan ik er dan aan doen. Ik heb de drift file als eens verwijderd.

[Coen Rosdorff]

Hou je even goed in de gaten dat die offset in milliseconden is? 1200ms is veel, maar niet extreem. Wat wel hoog is, is je jitter....

De grote vraag is of het na een paar uur minder gaat worden. 1,2 seconde moet toch maximaal in een dag wel weggewerkt zijn. De waarde van 'reach' doet vermoeden dat je ntpd pas net gestart hebt.

code:

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        LOCAL(0)        10 l   38   64  377    0.000    0.000   0.008
 192.168.0.255   0.0.0.0         16 -    -   64    0    0.000    0.000 4000.00
+obelix.xs4all.n ntp0.nl.uu.net   2 u   91 1024  377    9.494   -1.589   0.039
+auth1.xs4all.nl ntp1.nl.uu.net   2 u  100 1024  377    9.454   -3.297   0.661
-auth2.xs4all.nl ntp0.nl.uu.net   2 u   75 1024  377    9.667   -0.485   4.109
*auth3.xs4all.nl ntp1.nl.uu.net   2 u  655 1024  377   10.591   -2.549   0.101
-auth4.xs4all.nl ntp0.nl.uu.net   2 u  659 1024  377    9.489   -4.811   0.158
ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1   788  9014   yes   yes  none    reject   reachable  1
  2   789  8000   yes   yes  none    reject
  3   790  9414   yes   yes  none  candidat   reachable  1
  4   791  9414   yes   yes  none  candidat   reachable  1
  5   792  9314   yes   yes  none   outlyer   reachable  1
  6   793  9614   yes   yes  none  sys.peer   reachable  1
  7   794  9314   yes   yes  none   outlyer   reachable  1

Draai altijd voordat je ntpd start ntpdate [commands enzo...] om de tijd 1 malig even goed te zetten.
Verder kan je ook ntp2-1 t/m ntp2-4.xs4all.nl gebruiken. Met twee servers kan je ernstig de verkeerde kant op synchroniseren als één van die twee servers de weg kwijt raakt.

[ Voor 3% gewijzigd door Coen Rosdorff op 31-12-2005 02:30 ]

[raswic]

De jitter is enorm hoog en blijft zo. Na een half uur wordt de klok weer een stuk de goede kant op gezet en vervolgens verloopt ie weer. Ieder half uur begint dus ook de hele cyclus weer opnieuw zodat de waarde van reach altijd laag blijft.

Ik had overigens meer tijdservers ingesteld maar ik heb er nu even twee totdat dit probleem uit de wereld is.

Mijn idee is dat die jitter omlaag moet, ik weet alleen niet hoe.

[raswic]

* SCHOP *

Niemand een idee?

[BoAC]

www.ntp.org al doorgespit?
Daar wordt wel het eea over Redhat ntp-servers gezegd dat die meer jitter kunnen veroorzaken. Ook al nadere ntp-servers geprobeerd? Deze zijn ook te vinden via ntp.org

[Sjonny]

is je systeem klok niet gewoon stuk?
als je ntp uitzet, hoe snel gaat je klok dan fout lopen? ntp weet daar waarschijnlijk niet tegenop te boksen omdat het maar kleine veranderingen per keer verwerkt dacht ik

[raswic]

Je kan wel eens gelijk hebben, de klok loopt 15 seconden per uur verkeerd.

Is daar niets tegen te doen?

Overigens is het wel vreemd dat zowel mijn server als mijn desktop het probleem hebben.

Is het misschien een probleem van het moederbord? Dat zijn beide a7n8x borden met dus een nForce chipset.

[ Voor 49% gewijzigd door raswic op 04-01-2006 22:17 ]

[koffiedrinker]

Misschien is de CMOS-batterij leeg en loopt daarom je klok steeds verder achter.

[ Voor 6% gewijzigd door koffiedrinker op 05-01-2006 15:27 . Reden: typo ]