Hans Jørgen Jakobsen wrote:
> On Sun, 23 Jun 2002 09:58:53 +0200, Michael Jenner wrote:
>
>>Hans Jørgen Jakobsen wrote:
>>
>>I hvilken situation vil ntpd begynde at hoppe mellem servere?
>
> Når der er en række servere med samme stratum, som er næsten
> lige gode.
Ok, men jeg skulle vist have spurgt: Er det et problem? Det burde IMHO
ikke være et problem for ntp, altså at den har adgang til næsten lige
gode tids-servere. Det burde nærmere være en fordel? Med mindre urene
ser lige gode ud, men er meget forskellige ... som indrømmet måske kan
forekomme hvis man opretter et lokalt netværk udelukkende baseret på pc ure.
>>Tak for de mange input. Jeg tror jeg er landet på følgende konfiguration:
>>
>>ntp1.lan:
>>-----------------
>>server 127.127.1.0
>>fudge 127.127.1.0 stratum 8
>>peer ntp2.lan
>>peer ntp3.lan
>>server ntp1.tele.dk minpoll 17 maxpoll 16
>>server ntp2.tele.dk minpoll 17 maxpoll 16
>
>
> Jeg ville umiddelbart tro at minpoll skulle være <= maxpoll.
Ups ja, det burde være:
server ntp1.tele.dk burst minpoll 16 maxpoll 17
server ntp2.tele.dk burst minpoll 16 maxpoll 17
> En sideeffekt vil være at tid til første synkronisering vil være
> 5*2^17 sekunder. (Der skal laves 5 (4?) poll inden ntpd tror
> den ved hvad klokken er)
Ok, det er jo ikke optimalt. En bedre opsætning er nok:
minpoll 6 maxpoll 17
> Hvis drift i pollperiode overstiger 128 ms vil
> den nok aldrig synkronisere fordi offset bliver for stor. Det kan
> du risikere hvis du starter med en ukalibreret maskine.
Ja, det kan jeg godt se kan være et problem. Jeg mener at have læst at
offset større end 1000 s (sanity level) bevirker at ntp opgiver at
synkronisere. Hvis jeg forstår det korrekt er risikoen ved en for høj
maxpoll at en stor drift kan bevirke at "skidtet" holder op med at
synkronisere. Det ville være rart med et par user-alert features i ntp
men ... Minimums krav til pc urene må være:
1000 / 2^17 = 7.6 ms per sekund (maksimalt tilladelig drift per sekund)
1000 / 2^13 = 122 ms per sekund
1000 / 2^10 = 977 ms per sekund
Og hvis man misser blot en enkelt pakke så bliver kravene endnu skrappere.
Det kan godt være jeg skal holde mig fra maxpoll på 17 - hvis ovennævnte
er sandt. Jeg ender snart på default poll parametre:
minpoll 6 maxpoll 10
Det virker som om de er ret fornuftigt valgte
Hvad er typisk drift for et alm. pc ur? (Jeg har endnu ikke en ntp kørende)
> Forslag: Start uden minpoll parameter. Hvis det kører ordentlig
> vil poll alligevel hurtigt kravle op.
>
> Hvis du har en opkaldt forbindelse:
> Se på burst parameter. (jeg har ingen erfaring)
Ja den virker oplagt til formålet.
> Man kan også overveje at lave det sådan at ntp pakker
> IKKE kan bringe forbindelse op. evt kombineret med at
Med ip filtre? Det kræver vist at ip filtrene kan kigge på mere end
afsender/modtager adresser og protokol type.
> man sætter et lavt maxpoll, så man er sikker på at
> man får sendt nogen ntppakker når forbindelsen kommer
> op i anden anledning.
God ide, det vil jeg prøve.
>>restrict ntp1.tele.dk nomodify
>>restrict ntp2.tele.dk nomodify
>>restrict 127.0.0.1
>
> man side antyder at man ikke kan bruge symbolske navne i restrict
> (
http://www.eecis.udel.edu/~ntp/ntp_spool/html/accopt.htm)
Jeg vidste det egenligt godt - det var lettere at skrive med navne.
> Da der engang var en fejl i ntpd var en del af standardkonfigurationen:
> restrict default noquery
> restrict 127.0.0.1
>
> ie noquery isf nomodify
> Det ville jeg i det mindste gøre mod de externe servere.
> (Og som administrator af ntp1/2.tele.dk vil vi normalt ikke give os til
> at lave queries mod klienter, så det generer ikke mig
Hehe ... interessant oplysning der! Det gør jo ikke denne snak mindre
interessant, tværtimod
Lyder som et godt forslag - så vidt jeg lige kunne læse er noquery mere
begrænsende end nomodify så ja.
>>Men i og med ntp2.lan og ntp3.lan ikke har adgang til en lav-stratums
>>server bliver de vel nærmest degraderede til klienter og jeg kan ikke se
>>fordelen ved at de indgår som peer med ntp1.lan?
>
> Det kan godt være at du har et point der.
> (det er muligt at der i opstartsfasen af ntp1.lan vil være synkronisering
> med ntp2/3.lan)
> (Jeg kommer iøvrigt i tvivl om der skal en prefer på fudge statement.
> Måske er det kun når man skal til at lege med broadcast?)
Fra dokumentationen (driver 127.127.1.x):
In the default mode the behavior of the clock selection algorithm is
modified when this driver is in use. The algorithm is designed so that
this driver will never be selected unless no other discipline source
is available. This can be overridden with the prefer keyword of the
server configuration command, in which case only this driver will be
selected for synchronization and all other discipline sources will be
ignored. This behavior is intended for use when an external discipline
source controls the system clock.
Det lyder ikke som om jeg skal bruge prefer, da den så sætter alm. ntp
opførsel ud af kraft. Så vidt jeg kan se giver konfigurationen nu
følgende situation:
ntp1.lan (stratum 8) bruger ntp1.tele.dk eller ntp2.tele.dk (den anden
som første backup), og den har ntp2.lan, ntp3.lan og pc uret som backup
(hhv. 2., 3. og 4. backup-mulighed).
ntp2.lan (stratum 10) bruger ntp1.lan, ntp3.lan som første backup, pc
uret som sidste backup.
ntp3.lan (stratum 12) bruger ntp1.lan, ntp2.lan som første backup, pc
uret som sidste backup.
De lokale klienter bruger ntp1.lan, ntp2.lan som første backup, ntp3.lan
som sidste backup-mulighed.
Men hvad sker der i det øjeblik ntp1.tele.dk og ntp2.tele.dk ikke er
tilgængelige? ntp1.lan havde før stratum 2 (1+ntp1.tele.dk) - vil den
degradere sit stratum? Og de andre ntp servere vil måske også degradere
deres stratum? Måske indtil de finder ud af at der ikke findes nogle
disciplinerede ure - og pc uret i ntp1.lan vil vinde, hvorefter stratum
vil blive ntp1.lan(8), ntp2.lan(9) og ntp3.lan(9), eller?
Omvendt ser det ud til at "prefer" udelukker alle andre end pc uret,
inklusiv ntp1.tele.dk og ntp2.tele.dk, hvorfor det ikke virker som en
option.
Iøvrigt indikerer ovenstående text fra dok. at man faktisk skal køre med
mindst 4 lokale ntp servere som indgår i et peer netværk - for at de
hver især har adgang til mindst 3 servere - da uret i hver enkelt host
ikke også indgår.
Jeg er efterhånden tilbage i en mere minimalistisk opsætning:
ntp1.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 8
server ntp1.tele.dk
server ntp2.tele.dk
ntp2.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server ntp1.lan
peer ntp3.lan
ntp3.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 12
server ntp1.lan
peer ntp2.lan
+restrict linier.
Om ntp3.lan er med eller ej, betyder vist ikke det store.
Hvis man har to subnet med usikker forbindelse kan serverne med fordel
anbringes:
Subnet#1 (med adgang til Internet): ntp1.lan
Subnet#2 (uden adgang til Internet): ntp2.lan og ntp3.lan
> Iøvrigt skal du i start af ntp1.lan have en
> ntpdate ntp1.tele.dk ntp2.tele.dk ntp2.lan ntp3.lan
> (det vil sikre at klokken hives nogenlunde på plads inden ntpd startes)
Ja, det kan fint indbygges i /etc/init.d/ntp scriptet.
Mvh Michael