FreeBSD en de tijd

[Dennis]

Ik heb hier een FreeBSD server die in de toekomst als router gaat fungeren. Op dit moment verzorgt hij alleen nog maar DHCP en RTADVD. De volgende stap is nu dat al mijn computers in mijn netwerk de juiste tijd krijgen. Dus, dan zorg je dat de NTPD service wordt gestart zodat de tijd netjes wordt gesynchroniseerd.

Zo gezegd, zo gedaan en dus draait die service nu. In de /etc/ntp.conf staat:

code:

server ntp.xs4all.nl prefer

driftfile /var/db/ntp.drift

De tijd op deze server van xs4all is okay, als ik hem hier gelijk zet op mijn werkstation komt de tijd gewoon overéén.

Het probleem is echter dat de tijd een beetje sneller loopt dan de bedoeling is, sinds ik die NTPD service draai. Op mijn FreeBSD bak dus.

Als ik als test het 'date' commando gebruik en 2 seconden later nog eens, is de tijd vaak al 12 seconden vooruit gesprongen. Ik heb geen idee waar het door komt. Als ik ntpdate wil gebruiken is de socket al in use, maarja, met éénmalig terugzetten kom ik niet ver.

Met zoeken ben ik al zover gekomen dat het te maken zal hebben met mijn systemdrift. Maar hoe steekt dit precies in elkaar? Mijn BIOS-clock loopt gewoon prima, alleen FreeBSD heeft blijkbaar een eigen clock die het gebruikt daar bovenop.

Ik draai FreeBSD 5.2 op een vrij oude machine, een AMD K6-II 500.

Kan iemand mij uitleggen wat nu de bedoeling is?

[Verwijderd]

Is je ntpd niet toevallig je klok aan het updaten naar de tijd van xs4all (ff ntpq -c pee output posten svp). Ook kan het zijn dat je een ander timekeeping algoritme moet gebruiken. (heb geen fbsd bak bij de hand, maar sysctl -a | grep time moet je al een heel eind op weg helpen)

[Dennis]

Dat hij aan het updaten is had ik eerst ook aan gedacht. Maar ik heb de NTPD service twee dagen terug gestart en ondertussen is het al zaterdag op mijn FreeBSD bak. Ik neem aan dat mijn systeemklok nooit zó enorm fout kan staan.

Dit is de output van het door jou genoemde commando:

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================

 auth1.xs4all.nl ntp0-rz.rrze.un  2 u   50   64  377   40.031  -239467 32000.4

Wat je met dat laatste precies bedoeld begrijp ik totaal niet overigens .

[Spider.007]

Ligt het probleem niet aan de foute (?) offset die gebruikt wordt? Is het niet mogelijk die te corrigeren?

quote: http://freeunix.dyndns.org:8088/site2/howto/NTP2.shtml

In NTP these time references are also named stratum 0, the highest possible quality. (Each system that has its time synchronized to some reference clock can also be a time reference for other systems, but the stratum will increase for each synchronization.) A reference clock will provide the current time, that's for sure. However, NTP will compute some additional statistical values that describe the quality of time it sees. Among these values are: offset (or phase), jitter (or dispersion), frequency error, and stability . Thus each NTP server will maintain an estimate of the quality of its reference clocks and of itself.

[Verwijderd]

Niet alleen dat, freebsd doet per-default niet in 1 x de tijd verhogen (zoals een ntpdate -b), maar doet dat met zogeheten steps. Deze steps zorgen ervoor dat de tijd niet absoluut geset word, maar dat dat gedurende langere tijd met fracties van het tijdsverschil ge-update word (om te voorkomen dat er processen zijn die over de zeik gaan als ze geconfronteerd worden met een groot verschil van tijd, net zoals logging van verschillende hosts wat opeens niet makkelijk meer in context te lezen is). Wat je kunt proberen is het volgende (hiermee weet je iig dat je een cleane state hebt voor je ntp setup en je kijkt of bovenstaand verhaal voor jou van toepassing is):

- Stop de ntp server
- Forceer de juiste tijd (dmv ntpdate -b)
- Start de ntp server

Mocht dit het probleem niet verhelpen, zijn er nog een aantal andere dingen. Een daarvan is het algoritme wat gebruikt word om de klok te laten lopen. Dit algoritme bepaald hoe de tijd bijgehouden word, en kan dus van invloed zijn op de afwijking die bij jou optreed. (sterker nog, ik denk dat deze thread je ms wel verder kan helpen). Nog iets, waar jij ws geen last van hebt, maar wat ik iig wel bemerk (iig op freebsd/alpha) is dat de microuptime() routine soms failed onder zware load, waardoor de klok opeens een paar minuten (of nog meer) gaat achterlopen. Bovenstaand truukje (stop ntpd, ntpdate, start ntpd) lost dit probleem meestal vrij snel op.

[ Voor 16% gewijzigd door Verwijderd op 02-06-2004 15:43 ]

[Dennis]

Dankjewel, r3boot. Zoals ik zei gebruik ik een oud moederbord en daar zal idd geen goede ACPI support opzitten. Het linkje dat je gaf had meteen effect, dat werkt nu perfect.

Waar ik nu ff mee zit is dat als ik jouw andere commando intyp, ntpdate -b, ik dit krijg:

code:

k6-500mhz# ntpdate -b
 2 Jun 17:58:05 ntpdate[558]: no servers can be used, exiting

Ondanks dat ik ntp.xs4all.nl hier kan gebruiken (althans, geen foutmelding) wilde ik niks uitsluitend dus heb even een extra ntp-server ingevoegd in /etc/ntp.conf maar dit had geen effect.

Nu wil ik eigenlijk even kijken of ntpd wel netjes zijn tijd exact zet of dat dat ook niet lukt. Weet iemand hoe ik dit kan bekijken?

[Verwijderd]

hehehe, ik bedoelde dat meer in de zin dat je de -b parameter moest gebruiken voor ntpdate. De syntax die jij moet gebruiken om mbv ntpdate je klok te syncen is het volgende:

code:

ntpdate -b ntp.xs4all.nl

Het is altijd aan te raden om meerdere stratum 1/2 ntp servers in je ntp.conf te hebben. Hierdoor voorkom je dat jouw klok al te erg beinvloed word door een foutieve stratum 1/2 server. Gebruik hiervoor bijvoorbeeld 2~3 x onderstaande regel in je ntp.conf (pool.ntp.org is een round-robin adres waar zga alle publiekelijke ntp servers tussenstaan):

code:

server pool.ntp.org

Je kunt checken of ntp goed werkt door het volgende commando te runnen:

code:

ntpq -c pee (of ntpq -c pee eenhost als je de ntp server van eenhost wilt checken)

Hierbij zijn de volgende kolommen voor jou interesant:

code:

remote    De ntp server waarna je queried
st        Het "stratum" niveau van deze server (Lees de docs van ntp er ff op na 
          wat een stratum is, is ff teveel om uit te leggen ;) )
delay     Dit is het aantal miliseconden delay wat je hebt tussen jouw machine en remote
offset    Offset in seconden(met milliseconden precisie) ten opzichte van de klok van remote
jitter    De afwijking tussen een ntp update message en de daadwerkelijke klok (de fudge factor)

Overigens, als je meer wilt weten over ntp ('t is echt een boeiend onderwerp) dan moet je de ntp documentatie eens gaan doorspitten, daar staat nog veel meer nuttige informatie in (waarom een klok in een pc waardeloos is bijvoorbeeld )