[ntp] hoe timesync controleren?

[Booster]

Ik heb me helemaal blauw gezocht naar een *goeie* uitleg over de ntp.conf file, maar heb alleen onvolledige documentatie kunnen vinden helaas.

Uiteindelijk werd ik het zo beu, dat ik gewoon mijn ntp.conf maar gevult heb met wat ik dacht dat goed was.

code:

server ntp.xs4all.nl
server ntp0.cistron.nl

restrict 127.0.0.1 notrust notrap

driftfile /etc/ntp.drift
logconfig =all
logfile /var/log/ntp

• hierna ntpd gedraait, deze draait (een dag later) nogsteeds netjes
• ntpq -p geeft netjes een resultaat:

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*fistix.xs4all.n ntp0.NL.net      2 u   95 1024  377   54.965    4.333   7.709
+lwaxana.cistron ntp1.belbone.be  3 u  360 1024  377   43.081  -22.305 291.770

Wat in principe inhoud dat de ntpd goed draait.
• hierna een ntpdc -c kerninfo :

code:

pll offset:           0.000144 s
pll frequency:        -21.999 ppm
maximum error:        0.297068 s
estimated error:      0.128025 s
status:               0001  pll
pll time constant:    6
precision:            1e-06 s
frequency tolerance:  512 ppm
pps frequency:        0.000 ppm
pps stability:        512.000 ppm
pps jitter:           0.0002 s
calibration interval: 4 s
calibration cycles:   0
jitter exceeded:      0
stability exceeded:   0
calibration errors:   0

Ook hier alles in orde op het eerste gezicht.
• cat /etc/ntp.drift

code:

-22.000

• maar TOCH nog de volgende logentries die mij wat vreemd overkomen:
cat /var/log/ntp :

code:

22 Sep 19:57:39 ntpd[17945]: signal_no_reset: signal 17 had flags 4000000
22 Sep 19:57:46 ntpd[17945]: signal_no_reset: signal 14 had flags 4000000

[...]

code:

22 Sep 16:29:23 ntpd[28292]: offset -0.018826 sec freq -21.325 ppm error 0.017414 poll 10
22 Sep 17:29:23 ntpd[28292]: offset -0.020451 sec freq -21.585 ppm error 0.020187 poll 10
22 Sep 18:29:23 ntpd[28292]: offset -0.009323 sec freq -21.974 ppm error 0.082372 poll 10
22 Sep 19:29:23 ntpd[28292]: offset 0.016586 sec freq -22.000 ppm error 0.146961 poll 10

Zoals jullie zien dus om het uur een error.

Ik heb de volgende vragen:
• Hoe zit het met deze errors, zijn ze te negeren of weg te werken?
• Is de inhoud van mijn ntp.conf correct?
Houd hierbij in gedachte dat ik zelf GEEN ntp-server wil draaien (restrict default ignore)
Heeft er iemand een complete resource wat ntp.conf betreft?

Ik vond de volgende link:
http://www.freebsd.org/do...1/books/handbook/ntp.html
En die heeft me weer een stukje verder geholpen, maar toch vertrouw ik het niet 100%

[ Voor 0% gewijzigd door Booster op 22-09-2002 20:09 . Reden: toevoeging ]

[DennisBoom]

error slaat in de geval op de afwijking (error) van jouw interne clock ten opzichte van de klok waarmee je synchroniseert. Niets om je druk over te maken dus.

[Booster]

ok, hij bekijkt dus om het uur mijn afwijking en report die naar de logs?

[Verwijderd]

Waarom zit je met ntpd te experimenteren als je geen server wilt draaien ? ntpdate <server> is het client commando.

[_JGC_]

gewoon elke dag /etc/init.d/ntpdate schedulen.
Wel ff de output van dat ding naar /dev/null redirecten, of gewoon uit het script slopen, anders word je elke dag gemaild (in mijn geval elk uur, das pas irri)

[Booster]

Verwijderd schreef op 22 september 2002 @ 21:21:
Waarom zit je met ntpd te experimenteren als je geen server wilt draaien ? ntpdate <server> is het client commando.

• ntpd is zowel server als client, de beredenering ntpd = server en ntpdate = client is fout
• ntpdate is een totaal ander programma met een ander doel: het setten van de tijd, zonder daarover na te hoeven denken
• ntpd set ook de tijd, maar werkt met drifts en houd statistieken bij indien nodig
• ntpd kan door het opslaan van de drift ook de tijd corrigeren zonder dat er een ntp-server available is
• ntpd zal niet de tijd verzetten als het tijdsverschil tussen de local en remote te groot is ivm veiligheid (denk aan databases die over de zeik slaan bij het terugzetten van tijden). Het zal eerst analyseren of de remote wellicht over een verkeerde tijd beschikte, of dat de local gewoon ineens zeer ver is afgedreven.

Zie ook http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-config.htm

_JGC_ schreef op 22 september 2002 @ 22:01:
gewoon elke dag /etc/init.d/ntpdate schedulen.
Wel ff de output van dat ding naar /dev/null redirecten, of gewoon uit het script slopen, anders word je elke dag gemaild (in mijn geval elk uur, das pas irri)

Zie boven, dat is dus niet echt een nette manier. (en kan bovendien dus 'gevaarlijk' worden)