Archiv verlassen und diese Seite im Standarddesign anzeigen : NTP: Zeiten laufen auseinander II
Hi Leute,
eigenartiges Phänomen:
habe einen NTP Server (4.2) auf einem Windows XP Rechner laufen, jeder Linux Client benutzt ebenfalls den NTP 4.2 als Client, um seine Systemzeit mit dem XP Rechner zu synchronisieren. Ich kann ja per ntpq -p schauen, wann sich der NTPD das nächste mal auf den XP Rechner synchronisiert. Wenn ich während dieses Synchronisationsvorgangs massiv Traffic auf der selben Netzwerkstrecke, als auch massiv Last auf dem Client und dem Server mache (über andere Dinge), so laufen die Zeiten der beiden Systeme trotz laufendem NTP recht schnell auseinander (ca. 50ms nach 5 Minuten, Tendenz steigend). Auch wenn ich mit der Last-Erzeugung aufhöre, erholt sich NTP nicht wieder. Die Zeiten laufen weiter auseinander, obwohl sich NTP noch immer auf den Server zu synchronisieren versucht.
Irrtum... auch ein Neustart des NTP Daemon auf den Clients hilft nicht, das Auseinanderdriften wieder zu stabilisieren...
Weiß jemand, wie dieses Problem zustande kommt, und wie man es beheben kann?
EDIT: die Differenzen verschwinden erst nach einer ganzen Weile wieder. Nach etwa einer Stunde hat sich das System wieder eingependelt. Aber das ist untragbar für uns hier. Es darf gar nicht erst zu so hohen Differenzen kommen! Wie kann man das verhindern?
EDIT: Kann es eventuell mit den Einstellungen "burst" und/oder "iburst" in dem "server" Eintrag in der ntp.conf zusammen hängen???
das verhalten ist vollkommen ok, by design. ntp prüft die synchonisation auf plausibilität und verwirft u.U. die pakete. wenn du die laufzeiten durch traffic beeinflusst, braucht ntp einige zeit (stunden), um das zu kompensieren (die abweichung zu messen).
wenn dir 50ms abweichung zuviel sind, mach die synchronisation über ein eigenes netzwerk oder schliesse an jeden server ein dcf77 an. atomuhr wäre wohl etwas übertrieben.
-j
Dann finde ich jedoch eigenartig, daß dieses Verhalten nur auftritt, wenn die Parameter "burst" und "iburst" in der ntp.conf gesetzt sind. Entferne ich diese, habe ich zwar zwischenzeitlich vereinzelte Ausreißer, aber primär sind die Zeitdifferenzen minimalst zwischen -10 und +10 ms.
Leider ist der Anschluss einer DCF77 nicht realisierbar, da die Geräte teilweise in Kellergewölben zum Einsatz kommen, wo kein Signal einer Funkuhr jemals hinkäme. Und das ganze über GPS zu realisieren, würde den Preis der Systeme in unvertretbare Höhen treiben.
Dann finde ich jedoch eigenartig, daß dieses Verhalten nur auftritt, wenn die Parameter "burst" und "iburst" in der ntp.conf gesetzt sind. Entferne ich diese, habe ich zwar zwischenzeitlich vereinzelte Ausreißer, aber primär sind die Zeitdifferenzen minimalst zwischen -10 und +10 ms.
dein 'burst'-edit hab ich glatt übersehen.
burst macht da, was man vermutet: sende mehrere pakete hintereinander um die synchronisierung zu beschleunigen (für dialup gedacht).
wenn der burst aber gerade mit heavy traffic zusammenfällt, weichen die messwerte stark voneinander ab. grosse messfehler -> starke abweichung. ntp läuft am besten, wenn die netzwerklast immer gleich ist (gleiche paketlaufzeiten) und kontinuierlich gemessen wird (um die drift der RTC festzustellen).
-j
Ab und an editiere ich meine Posts mal, wenn ich neue Informationen habe, bzw. selbst schon weitere Erkenntnisse gewonnen habe. Ist nur, um Doppelposts zu vermeiden.
Konstanter Traffic ist bei uns leider nicht der Fall. Hauptsächlich findet nur sehr wenig Traffic auf das Gerät statt, ab und an mal doch recht viel. Das aber dann wieder nur kurzzeitig. Es ist also alles recht dynamisch. Daß man damit nur schwer eine Zeitsynchronisation über das Netzwerk bekommt, scheint also ein Problem nicht zu behebender Art zu sein. Naja, müssen wir uns wohl mit abfinden.
So, wie es jetzt ist, ohne Burst und IBurst, scheint es ja zu funktionieren.
Wie geht das mit dem Drift File? Wie frequent hält NTP die Systemuhr per Drift File synchron? Also wie oft korrigiert NTP die Systemuhr nach dem Driftfile? Permanent? Alle x Sekunden/Minuten?
Ab und an editiere ich meine Posts mal, wenn ich neue Informationen habe, bzw. selbst schon weitere Erkenntnisse gewonnen habe. Ist nur, um Doppelposts zu vermeiden.
vollkommen ok.
Wie geht das mit dem Drift File? Wie frequent hält NTP die Systemuhr per Drift File synchron? Also wie oft korrigiert NTP die Systemuhr nach dem Driftfile? Permanent? Alle x Sekunden/Minuten?
du willst es aber ganz genau wissen :)
das drift-file wird stündlich aktualisiert und dient nicht zum direkten nachregeln der kernel-uhr, sondern nur zum speichern der frequenz für den kernel-pll (ist kein drift-file da, muss ntp erst eine messung machen um einen groben anfangswert zu erhalten, bevor er mit der eigentlichen zeitkorrektur anfangen kann). ein pll ist ein gesteuerter regelkreis, d.h. ich fange mit wert x an, prüfe ob der regelwert stimmt, wenn nicht, regele ich solange nach, bis der wert stimmt, und das ununterbrochen.
die kernel-uhr wird beim booten aus der rtc initialisiert und wird danach nur durch den pll korregiert. was ntp nun macht, ist an den stellschrauben des pll zu drehen, um den regelkreis möglichst genau auf die per ntp-protokoll ermittelte zeit zu bringen. auch das ist ein kontinuierlicher prozess.
wenn du ntp bei der arbeit zugucken willst, mach ein 'watch -d -n 1 'ntpdc -c kerninfo -c peers' und beobachte 'pll offset', 'pll frequency' und 'offset'. und vergleich mal 'pll frequency' mit dem wert aus dem driftfile.
-j
Na klar will ich's ganz genau wissen. :D Darum schreib ich's ja hier. ;)
pll frequency ist -52.463, während im Drift File steht 53.319. pll offset liegt immer zwischen -9e-05 und -0.000120 Sekunden. Offset lag zuletzt bei 0.000121 Sekunden. Ausgabe:
pll offset: -5e-06 s
pll frequency: -52.462 ppm
maximum error: 0.039317 s
estimated error: 0.000385 s
status: 0001 pll
pll time constant: 0
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
remote local st poll reach delay offset disp
================================================== =====================
*136.1.255.27 136.1.101.17 13 16 377 0.00055 0.000121 0.00098
ISTS [~]# cat /var/cache/ntp.drift
52.319
ISTS [~]#
pll frequency ist -52.463, während im Drift File steht 53.319.
das ist schon ok, das driftfile wird stündlich aktualisiert und zeigt damit nur 1x pro stunde den gleichen wert wie ntpdc an.
mal so aus neugier: wieviel MHz hat die CPU? mein PII-300 ist schon etwas betagter und ist CPU-mässig immer zu 50% ausgelastet:
pll offset: -0.012838 s
pll frequency: 18.245 ppm
maximum error: 0.569822 s
estimated error: 0.012541 s
status: 0001 pll
pll time constant: 6
precision: 1e-06 s
wie man sieht, hat deine zeit einen bedeutend geringeren fehler.
remote local st poll reach delay offset disp
================================================== =====================
*136.1.255.27 136.1.101.17 13 16 377 0.00055 0.000121 0.00098
du solltest die lokale uhr als fallback (höchstes stratum) mit reinnehmen, so dass ntp immer eine synchronisationsquelle hat.
normalerweise hat eine echte synchonisationsquelle ein stratum von 1-6 und die lokale stratum 10. warum hat dein peer ein stratum von 13?
-j
Achso...
Letztgenanntes frage ich mich auch. In der ntp.conf steht drin
fudge 136.1.255.xxx stratum 1
was aber auf den Wert keinen Einfluss zu haben scheint.
Die CPU auf dem Board ist ein PII 266MHz.
Kleine Erklärung zu den Systemen:
Es handelt sich dabei um VME Baugruppen, auf denen halt ein vollwertiges Linux seinen Dienst tut. Darauf läuft eine Loader-Software, die von mir entwickelt wurde (siehe Thread bei Mr. Unix über GNU Readline & Telnet und so). Wird auf die Baugruppe über meine Software zum ersten Mal nach dem Starten der Baugruppe eine Lade-Software geladen, eine Art Firmware geladen, so wird in der ntp.conf die IP von der Gegenstelle eingetragen (die IP von der Download Quelle), welche immer einen NTP Daemon laufen hat. Auch bei einem Wechsel der Quelle (was recht selten vorkommt), wird die IP geändert und der Daemon neu gestartet. Daher denke ich auch, daß es sinnvoll ist, den lokalen NTP Daemon mit einzutragen. Ich werde das korrigieren.
Letztgenanntes frage ich mich auch. In der ntp.conf steht drin
fudge 136.1.255.xxx stratum 1
warum 'fudge' und warum gibst du ein stratum an?
136.1.255.xxx ist doch keine referenzuhr wie gps, dcf77, cäsium, etc.
probier mal:
server 136.1.255.xxx
fudge 127.127.1.0 stratum 10
das sollte dir 2 peers geben. das stratum von 136.1.255.xxx wird automatisch übermittelt,127.127.1.0 ist die RTC als fallback. das fudge-stratum muss nicht 10 sein, sollte aber grösser 16 sein, weil 16 ist 'unsynchronized'.
sollte 136.1.255.xxx nicht erreichbar sein, synchonisiert sich ntp mit der RTC. sobald 136.1.255.xxx wieder online ist, schwenkt ntpd wieder zurück, weil 136.1.255.xxx ein geringeres stratum hat.
-j
Gefährliches Halbwissen meinerseits. Was bedeutet 'fudge'? Dachte immer, das ist nur zum manuellen Setzen des Stratum-Levels. Wenn dem nicht so ist, bitte ich um Aufklärung.
Also der Rechner "PC1", der direkt auf unseren primären NTP Server "NTP1" zugeift, läuft jetzt mit selbigem annehmbar synchron. Jetzt kommt was neues hinzu:
Hinter besagtem Rechner "PC1" hängen weitere Rechner in einem anderen Subnetz. Rechner PC1 hat also zwei Netzwerk Interfaces eth0 und eth1. eth0 belegt das Netzwerk 136.1.0.0/16, eth1 belegt 10.1.1.0/24. Die Rechner hinter PC1 synchronisieren sich deshalb mit PC1, welcher sich wiederum, wie oben beschrieben mit NTP1 synchronisiert.
Leider scheint die Synchronisation der einzelnen Rechner hinter PC1 mit PC1 noch nicht richtig zu funktionieren. Jedenfalls hab ich teilweise eine Diskrepanz von >300ms zwischen PC1 und einem im Subnetz 10.1.1.0/24 hängenden System. Das Netzwerk unter dem SubNetz 10... ist wesentlich langsamer, als das zwischen PC1 und NTP1. Kann das damit zusammen hängen?
Wie kommt diese Differenz zustande und wie bekomme ich sie weg?
Gefährliches Halbwissen meinerseits. Was bedeutet 'fudge'? Dachte immer, das ist nur zum manuellen Setzen des Stratum-Levels. Wenn dem nicht so ist, bitte ich um Aufklärung.
eigentlich hatte ich hierauf bereits vor tagen geantwortet, aber der beitrag ist verschwunden. also nochmal:
'fudge' ist eigentlich zum konfigurieren von pseudo-devices, also clocksources wie dcf77, gps, radio, modem oder atom.
deshalb kann man bei 'fudge' u.a. ein stratum angeben. ich weiss nicht, ob ein manueller override des stratum einer ntp-quelle mittels fudge ohne probleme möglich ist. wie man sieht, geht es technisch, vielleicht hat es aber nebeneffekte.
-j
Leider scheint die Synchronisation der einzelnen Rechner hinter PC1 mit PC1 noch nicht richtig zu funktionieren. Jedenfalls hab ich teilweise eine Diskrepanz von >300ms zwischen PC1 und einem im Subnetz 10.1.1.0/24 hängenden System. Das Netzwerk unter dem SubNetz 10... ist wesentlich langsamer, als das zwischen PC1 und NTP1. Kann das damit zusammen hängen?
eigentlich nicht, da das prinzip von ntp unabhängig von der leitungsgeschwindigkeit ist. selbst 2400er modemlines funktionieren mit hoher genauigkeit. wichtig ist nur, dass die latenz für die hin- UND rückrichtung annähernd gleich ist. ansonsten führt die roundtripdelayberechnung zu falschen werten. ntp versucht zwar diese fehler herauszufiltern, aber bei grossen abweichungen kommt es zu fehlern.
Wie kommt diese Differenz zustande und wie bekomme ich sie weg?
da hilft nur monitoring der peers (und des kernel-pll falls verfügbar) über einen längeren zeitraum (1-2 tage). am besten auf mehreren kisten aus dem 10er netz.
ein einfacher cronjob sollte dafür ausreichen.
in abhängigkeit von der anzahl der rechner könnte man für das subnetz auch auf broadcast umstellen: PC1 holt zeit per polling von NTP1 und broadcastet in das 10er netz, die ntpd der anderen rechner laufen dann als broadcastclients. broadcast hat den vorteil, dass die roundtrip-berechnung entfällt, weil der client auf den broadcast nicht antworten muss. multicast ist auch möglich.
-j
Das Broadcasten klingt sehr interressant, da je 10er Netz (gibt diverse dieser 10er Netze) sowieso maximal 8 Hosts drin sind (10.1.1.100 - 10.1.1.108, wobei .100 jeweils der PC1 ist).
Zur Erklärung: es gibt mehrere PC1, die quasi als Bridge zwischen dem 136er und dem 10er Netz fungieren. Sie haben alle unterschiedliche 136er Adressen, aber die 10er Adressen sind immer gleich. Alle 10er Netze sind von einander unabhängig und bis auf Schicht 1 runter getrennt. Die einzige Verbindung zwischen den Netzen besteht über die PC1 Geräte und deren Einbindung in das 136er Netz.
Also Broadcast. Ich denke, das sollte gehen. Wie konfiguriert man das? Ich schaue parallel noch ins Manual.
Also Broadcast. Ich denke, das sollte gehen. Wie konfiguriert man das? Ich schaue parallel noch ins Manual.
auf server seite:
broadcast <broadcastadresse des gewünschten interfaces>
auf clientseite nur:
broadcastclient
evtl. noch broadcastdelay anpassen.
-j
Ich find das merkwürdig... und grausam.
Schau dir mal die Werte hinten in den Klammern hinter DIFF an! Das sind die gemessenen Delays (inklusive Paketlaufzeit) zwischen dem NTP1 und einem PC1 in Millisekunden. Die gehen rauf und runter und rauf und runter...
Ich begreif's nicht. :confused:
[1658386954] LINK [136.1.255.27:2927] <-- [136.1.254.41:24002]: RECV [402] (0) : TIME (3334047245523) IDFTIME (3334047245522) DIFF (-1)
[1658387284] LINK [136.1.255.27:2908] <-- [136.1.254.41:24012]: RECV [401] (0) : TIME (3334047245854) IDFTIME (3334047245851) DIFF (-3)
[1658388967] LINK [136.1.255.27:2910] <-- [136.1.254.41:24042]: RECV [402] (0) : TIME (3334047247536) IDFTIME (3334047247493) DIFF (-43)
[1658396948] LINK [136.1.255.27:2927] <-- [136.1.254.41:24002]: RECV [402] (0) : TIME (3334047255517) IDFTIME (3334047255523) DIFF (6)
[1658397279] LINK [136.1.255.27:2908] <-- [136.1.254.41:24012]: RECV [401] (0) : TIME (3334047255848) IDFTIME (3334047255852) DIFF (4)
[1658398921] LINK [136.1.255.27:2910] <-- [136.1.254.41:24042]: RECV [402] (0) : TIME (3334047257490) IDFTIME (3334047257494) DIFF (4)
[1658406973] LINK [136.1.255.27:2927] <-- [136.1.254.41:24002]: RECV [402] (0) : TIME (3334047265542) IDFTIME (3334047265525) DIFF (-17)
[1658407333] LINK [136.1.255.27:2908] <-- [136.1.254.41:24012]: RECV [402] (0) : TIME (3334047265902) IDFTIME (3334047265853) DIFF (-49)
[1658408925] LINK [136.1.255.27:2910] <-- [136.1.254.41:24042]: RECV [402] (0) : TIME (3334047267495) IDFTIME (3334047267495) DIFF (0)
[1658416957] LINK [136.1.255.27:2927] <-- [136.1.254.41:24002]: RECV [402] (0) : TIME (3334047275526) IDFTIME (3334047275527) DIFF (1)
[1658417287] LINK [136.1.255.27:2908] <-- [136.1.254.41:24012]: RECV [401] (0) : TIME (3334047275857) IDFTIME (3334047275854) DIFF (-3)
[1658460249] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [403] (0) : TIME (3334047318818) IDFTIME (3334047318435) DIFF (-383)
[1658470254] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047328823) IDFTIME (3334047328436) DIFF (-387)
[1658480248] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047338817) IDFTIME (3334047338437) DIFF (-380)
[1658490282] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047348852) IDFTIME (3334047348438) DIFF (-414)
[1658500287] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047358856) IDFTIME (3334047358439) DIFF (-417)
[1658510291] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047368860) IDFTIME (3334047368440) DIFF (-420)
[1658520296] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047378865) IDFTIME (3334047378441) DIFF (-424)
[1658530300] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047388869) IDFTIME (3334047388442) DIFF (-427)
[1658540314] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047398884) IDFTIME (3334047398443) DIFF (-441)
[1658550319] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047408888) IDFTIME (3334047408444) DIFF (-444)
[1658560363] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047418932) IDFTIME (3334047418445) DIFF (-487)
[1658570368] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047428927) IDFTIME (3334047428446) DIFF (-481)
[1658580372] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047438941) IDFTIME (3334047438447) DIFF (-494)
[1658590376] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047448946) IDFTIME (3334047448448) DIFF (-498)
[1658600381] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047458950) IDFTIME (3334047458449) DIFF (-501)
[1658609884] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [403] (0) : TIME (3334047468454) IDFTIME (3334047468450) DIFF (-4)
[1658619899] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047478468) IDFTIME (3334047478451) DIFF (-17)
[1658629933] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047488502) IDFTIME (3334047488452) DIFF (-50)
[1658639928] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047498497) IDFTIME (3334047498453) DIFF (-44)
[1658649942] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047508511) IDFTIME (3334047508454) DIFF (-57)
[1658659946] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047518516) IDFTIME (3334047518455) DIFF (-61)
[1658669941] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047528510) IDFTIME (3334047528456) DIFF (-54)
[1658679955] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047538524) IDFTIME (3334047538457) DIFF (-67)
[1658689950] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047548519) IDFTIME (3334047548458) DIFF (-61)
[1658699974] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047558543) IDFTIME (3334047558459) DIFF (-84)
[1658709968] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047568538) IDFTIME (3334047568460) DIFF (-78)
[1658719973] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047578542) IDFTIME (3334047578461) DIFF (-81)
[1658729977] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047588546) IDFTIME (3334047588462) DIFF (-84)
[1658739981] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047598541) IDFTIME (3334047598463) DIFF (-78)
[1658749986] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047608555) IDFTIME (3334047608469) DIFF (-86)
[1658760000] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047618569) IDFTIME (3334047618470) DIFF (-99)
[1658770015] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047628584) IDFTIME (3334047628471) DIFF (-113)
[1658780009] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047638578) IDFTIME (3334047638472) DIFF (-106)
[1658790003] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047648573) IDFTIME (3334047648473) DIFF (-100)
[1658799998] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047658567) IDFTIME (3334047658474) DIFF (-93)
[1658810002] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047668571) IDFTIME (3334047668483) DIFF (-88)
[1658820007] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047678576) IDFTIME (3334047678484) DIFF (-92)
[1658830021] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047688590) IDFTIME (3334047688485) DIFF (-105)
[1658840025] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047698595) IDFTIME (3334047698486) DIFF (-109)
[1658850030] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047708599) IDFTIME (3334047708487) DIFF (-112)
[1658860034] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047718603) IDFTIME (3334047718488) DIFF (-115)
[1658870028] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047728598) IDFTIME (3334047728489) DIFF (-109)
[1658880033] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047738602) IDFTIME (3334047738490) DIFF (-112)
[1658890027] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047748596) IDFTIME (3334047748491) DIFF (-105)
[1658900042] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047758611) IDFTIME (3334047758492) DIFF (-119)
[1658910036] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047768595) IDFTIME (3334047768493) DIFF (-102)
[1658920020] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047778590) IDFTIME (3334047778494) DIFF (-96)
[1658930025] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047788584) IDFTIME (3334047788495) DIFF (-89)
[1658940019] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047798588) IDFTIME (3334047798496) DIFF (-92)
[1658950003] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047808573) IDFTIME (3334047808497) DIFF (-76)
[1658959998] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047818567) IDFTIME (3334047818498) DIFF (-69)
[1658970012] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047828581) IDFTIME (3334047828499) DIFF (-82)
[1658980007] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047838576) IDFTIME (3334047838500) DIFF (-76)
[1658990001] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047848570) IDFTIME (3334047848501) DIFF (-69)
[1658999995] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047858565) IDFTIME (3334047858502) DIFF (-63)
[1659009980] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047868549) IDFTIME (3334047868503) DIFF (-46)
[1659019954] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047878523) IDFTIME (3334047878504) DIFF (-19)
[1659029948] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047888518) IDFTIME (3334047888505) DIFF (-13)
[1659039953] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047898522) IDFTIME (3334047898506) DIFF (-16)
[1659049927] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047908496) IDFTIME (3334047908507) DIFF (11)
[1659059912] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047918481) IDFTIME (3334047918508) DIFF (27)
[1659069896] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047928465) IDFTIME (3334047928509) DIFF (44)
[1659079880] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047938449) IDFTIME (3334047938510) DIFF (61)
[1659089885] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047948454) IDFTIME (3334047948511) DIFF (57)
[1659099899] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047958468) IDFTIME (3334047958512) DIFF (44)
[1659109913] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047968483) IDFTIME (3334047968513) DIFF (30)
[1659119918] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047978487) IDFTIME (3334047978514) DIFF (27)
[1659129932] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334047988501) IDFTIME (3334047988515) DIFF (14)
[1659139937] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334047998506) IDFTIME (3334047998516) DIFF (10)
[1659149941] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048008510) IDFTIME (3334048008517) DIFF (7)
[1659159945] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048018515) IDFTIME (3334048018518) DIFF (3)
[1659169970] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048028539) IDFTIME (3334048028519) DIFF (-20)
[1659179974] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048038543) IDFTIME (3334048038520) DIFF (-23)
[1659189979] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048048548) IDFTIME (3334048048521) DIFF (-27)
[1659199983] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048058552) IDFTIME (3334048058522) DIFF (-30)
[1659209997] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048068567) IDFTIME (3334048068523) DIFF (-44)
[1659220012] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048078581) IDFTIME (3334048078528) DIFF (-53)
[1659230026] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048088595) IDFTIME (3334048088537) DIFF (-58)
[1659240061] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048098630) IDFTIME (3334048098538) DIFF (-92)
[1659250065] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048108634) IDFTIME (3334048108539) DIFF (-95)
[1659260069] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048118639) IDFTIME (3334048118540) DIFF (-99)
[1659270064] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048128633) IDFTIME (3334048128541) DIFF (-92)
[1659280068] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048138637) IDFTIME (3334048138542) DIFF (-95)
[1659290072] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [403] (0) : TIME (3334048148642) IDFTIME (3334048148543) DIFF (-99)
[1659300067] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048158636) IDFTIME (3334048158544) DIFF (-92)
[1659310091] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [401] (0) : TIME (3334048168660) IDFTIME (3334048168545) DIFF (-115)
[1659320076] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048178635) IDFTIME (3334048178546) DIFF (-89)
[1659330060] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048188629) IDFTIME (3334048188547) DIFF (-82)
[1659340054] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048198624) IDFTIME (3334048198548) DIFF (-76)
[1659350039] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048208608) IDFTIME (3334048208549) DIFF (-59)
[1659360033] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048218602) IDFTIME (3334048218550) DIFF (-52)
[1659370037] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048228607) IDFTIME (3334048228551) DIFF (-56)
[1659380052] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048238621) IDFTIME (3334048238552) DIFF (-69)
[1659390046] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048248615) IDFTIME (3334048248553) DIFF (-62)
[1659400051] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048258620) IDFTIME (3334048258558) DIFF (-62)
[1659410045] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048268614) IDFTIME (3334048268559) DIFF (-55)
[1659420039] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048278609) IDFTIME (3334048278560) DIFF (-49)
[1659430034] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048288603) IDFTIME (3334048288561) DIFF (-42)
[1659440038] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048298607) IDFTIME (3334048298562) DIFF (-45)
[1659450032] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048308602) IDFTIME (3334048308566) DIFF (-36)
[1659460027] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048318596) IDFTIME (3334048318568) DIFF (-28)
[1659470011] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048328580) IDFTIME (3334048328569) DIFF (-11)
[1659480006] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048338575) IDFTIME (3334048338570) DIFF (-5)
[1659490000] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048348569) IDFTIME (3334048348571) DIFF (2)
[1659500004] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048358574) IDFTIME (3334048358576) DIFF (2)
[1659510029] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048368598) IDFTIME (3334048368577) DIFF (-21)
[1659520023] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048378592) IDFTIME (3334048378578) DIFF (-14)
[1659530028] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048388597) IDFTIME (3334048388579) DIFF (-18)
[1659540032] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048398601) IDFTIME (3334048398580) DIFF (-21)
[1659550036] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048408605) IDFTIME (3334048408581) DIFF (-24)
[1659560031] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048418600) IDFTIME (3334048418582) DIFF (-18)
[1659570035] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048428604) IDFTIME (3334048428583) DIFF (-21)
[1659580059] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048438629) IDFTIME (3334048438584) DIFF (-45)
[1659590074] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048448643) IDFTIME (3334048448592) DIFF (-51)
[1659600068] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048458637) IDFTIME (3334048458594) DIFF (-43)
[1659610073] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048468642) IDFTIME (3334048468595) DIFF (-47)
[1659620077] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048478646) IDFTIME (3334048478596) DIFF (-50)
[1659630081] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048488651) IDFTIME (3334048488597) DIFF (-54)
[1659640086] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048498655) IDFTIME (3334048498598) DIFF (-57)
[1659650110] LINK [136.1.255.27:3090] <-- [136.1.103.19:24001]: RECV [402] (0) : TIME (3334048508679) IDFTIME (3334048508599) DIFF (-80)
So schaut jetzt die NTP.conf auf dem PC1 aus:
ntp.conf
# NTP Conf generated by ISTS BIOS
#
server 136.1.255.27 minpoll 3 maxpoll 4
fudge 127.127.1.0 stratum 10
logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift
Das sagt mir ntpq -p:
remote refid st t when poll reach delay offset jitter
================================================== ============================
*136.1.255.27 LOCAL(1) 13 u 2 16 37 0.284 112.116 27.060
Und das sagt mir ntpdc's kerninfo:
ntpdc> kerninfo
pll offset: 0.04223 s
pll frequency: -383.008 ppm
maximum error: 0.032479 s
estimated error: 0.011324 s
status: 0041 pll unsync
pll time constant: 0
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
Was mich etwas irritiert ist der hohe pll-frequency Wert. Der liegt bei anderen Geräten irgendwo im Bereich von 50.
Schau dir mal die Werte hinten in den Klammern hinter DIFF an! Das sind die gemessenen Delays (inklusive Paketlaufzeit) zwischen dem NTP1 und einem PC1 in Millisekunden. Die gehen rauf und runter und rauf und runter...
also wenn das millisekunden sind, ist das heftig. ich hab 200ms zu kernel.org und das geht über 10 hops. wenn das kein fehler der netzwerkomponenten ist, sondern einfach durch sättigung des links, könnte QoS helfen. das hab ich bei mir ebenfalls konfiguriert. dadurch werden ausgehende ntp-pakete bevorzugt behandelt und die unterschiede sollten geringer werden.
Das sagt mir ntpq -p:
remote refid st t when poll reach delay offset jitter
================================================== ============================
*136.1.255.27 LOCAL(1) 13 u 2 16 37 0.284 112.116 27.060
wo ist LOCAL(0) hin? du synchronisierst gegen die lokale uhr (siehe refid) von NTP1. das erklärt auch das hohe stratum. wenn du der lokalen uhr auf PC1 ein stratum von 10 gibst, wird diese verwendet. allerdings wie oben zu sehen ist, synchronisierst du gegen NTP1, die lokale uhr taucht nicht auf. gibt 127.127.0.1 mal stratum 14, mal sehen ob sie dann als peer auftaucht.
status: 0041 pll unsync
status 0x41 bedeutet: 0x01=PLL enabled, 0x40=clock unsync. der ntpd synchronisiert den pll nicht. nach dem starten ist das ok, aber nach 15-30 min sollte dort status=1 stehen. irgendwelche meldungen im syslog?
-j
Sind Millisekunden. Ich finde das auch ziemlich heftig. Das sind Teilweise drei Stunden Unterschied. Die Differenzen in DIFF () beziehen sich auf die Uhr eines Client Systems (PC1 selbst, oder ein System im 10er Netz identifiziert und erreicht durch eine Portweiterleitung auf PC1) gegenüber NTP1.
Status ist jetzt auf allen drei Systemen (PC1 und die 10er Netz Systeme dahinter, ich nenn sie mal DIU0 und DIU5, wie sie auch hier im Team genannt werden) 0x0041.
QoS ist leider aus diversen Gründen hier keine Option für uns...
Ich habe die Konfigurationsdatei entsprechend geändert, was aber dennoch keinerlei Auswirkungen hat:
# NTP Conf generated by ISTS BIOS
#
server 136.1.255.27 minpoll 3 maxpoll 4
broadcast 10.255.255.255
server 127.127.1.0
fudge 127.127.1.0 stratum 14
logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift
So sieht sie jetzt aus. Aber trotzdem taucht die lokale Uhr des PC1 nicht in der Liste auf. Und daß er auf die Lokale Uhr von NTP1 synchronisiert, ist so gewollt. Es geht lediglich darum, die Systeme synchron zu bekommen, nicht um eine Exakte Uhrzeit. Es kann meinetwegen zu dieser Tageszeit auch überall 17:13:45'87 sein. Wichtig ist nur, daß es auf allen Systemen dann wirklich möglichst exakt 17:13:45'87 ist. Die Zeiten müssen bis auf 10ms genau sein. Eine externe Uhr, die genau geht, ist für unsere Zwecke nicht erforderlich. Wichtig ist die Synchronizität.
EDIT:
Oh, seit gestern ca. 15:42 steht in dem Logfile nur noch
sendto(136.1.255.27): Bad file descriptor
:eek: :eek: :eek:
Woran kann das liegen?
EDIT:
Ah mehrere ntpd Instanzen... korrigiert. Aber dennoch, Synchronisation funktioniert nicht. Vielleicht muss ich ja auch einfach ein bisschen mehr Geduld haben.
Jedenfalls zeigt mir ntpq -p auf PC1 jetzt das an:
remote refid st t when poll reach delay offset jitter
================================================== ============================
*136.1.255.27 LOCAL(1) 13 u 10 16 377 0.358 998.896 34.501
10.255.255.255 .BCST. 16 u - 64 0 0.000 0.000 4000.00
LOCAL(0) LOCAL(0) 14 l 49 64 17 0.000 0.000 0.001
Was ich mich frage ist, er kennt das Offset zum Server, warum korrigiert er es dann nicht?
Was ich mich frage ist, er kennt das Offset zum Server, warum korrigiert er es dann nicht?
ntpd ändert die zeit in kleinen schritten und nicht auf einmal. stoppe ntpd mal und rufe "ntpdate <ntp-server>" oder "ntpd -q" auf. das stellt die zeit sofort. danach ntpd wieder starten und mit 'peers' und 'kerninfo' feststellen, ob er die zeit synchronisiert.
du könntest auch mit 'peering' experimentieren. bisher hast du eine client-server-konfiguration, einer gibt vor, alle anderen ziehen nach.
mit peering einigen sich die peers auf eine zeit, je nachdem, welche zeit gerade genauer (weniger messfehler) ist.
verwendet man i.d.R. um zeitserver untereinander zu synchonisieren, also z.b. GPS mit DCF.
du könntest zum testen mal NTP1 mit PC1 als peer-paar konfigurieren und eine weile beobachten. die uhrzeit wird nicht unbedingt absolut genau sein, aber die unterschiede sollten geringer werden. ob peering allerdings für ein gesamtes netz sinnvoll ist und funktioniert, weiss ich nicht. habe ich bisher nur mit 3-4 zeitquellen gemacht.
-j
Hmm... Peering wäre vielleicht noch eine Möglichkeit.
Ich hab mal ntpd -q gemacht, nach beenden des NTP Daemons, dann den Daemon wieder gestartet und die Zeiten beobachtet. Innerhalb kürzester Zeit laufen die Uhren wieder auseinander. nach 1 Minute hat er schon wieder eine Differenz von knapp 100ms. Untragbar. Hilft es hier eventuell, das Driftfile zu löschen und darauf zu warten, daß er ein neues anlegt?
EDIT:
Auch ohne NTP Daemon laufen die Zeiten auseinander. Mit dem Daemon im Hintergrund sogar noch schneller. :confused:
EDIT:
jetzt hat er auf PC1 ein neues Driftfile angelegt mit dem Wert 500.000 drin. Die Differenz steigt jetzt nicht mehr kontinuierlich, schwankt aber zwischen -50 und -80ms, was auch noch untragbar ist. Vor allem muss das ganze mal STABIL auf die Beine zu stellen sein.
EDIT:
jetzt steht in der Log Datei zuhauf
25 Aug 12:31:27 ntpstandalone[22915]: frequency error 512 PPM exceeds tolerance 500 PPM
Was hat das jetzt schon wieder zu bedeuten? :confused: :confused: :confused:
Wie biege ich den NTP Daemonen auf den PC1 bei, daß der angegebenen Server NTP1 Stratum 1 haben soll? Die PC1 synchronisieren sich jetzt zwar wieder. Die PC2 im 10er Netz synchronisieren sich jedoch leider nicht auf den jeweiligen PC1. :confused:
25 Aug 12:31:27 ntpstandalone[22915]: frequency error 512 PPM exceeds tolerance 500 PPM
Was hat das jetzt schon wieder zu bedeuten? :confused: :confused: :confused:
die frequenz des pll ist beschränkt. das ist aber an sich kein problem, die synchronisation dauert halt nur länger.
-j
Wie biege ich den NTP Daemonen auf den PC1 bei, daß der angegebenen Server NTP1 Stratum 1 haben soll? Die PC1 synchronisieren sich jetzt zwar wieder. Die PC2 im 10er Netz synchronisieren sich jedoch leider nicht auf den jeweiligen PC1. :confused:
das stratum hat eigentlich keinen einfluss solange es < 16 ist (16 == nicht synchron).
das stratum wird immer um 1 hochgezählt, wobei stratum-0 für referenzuhren wie funk, etc. gedacht ist, d.h. die uhr hat stratum-0, der server, der seine zeit von dieser bezieht -> stratum-1. wenn PC1 also stratum-1 liefern soll, muss seine zeitquelle stratum-0 haben.
du musst also der local clock auf NTP1 ein stratum von 0 geben. kann aber sein, dass ntpd das nicht zulässt.
-j
das stratum hat eigentlich keinen einfluss solange es < 16 ist (16 == nicht synchron).
das stratum wird immer um 1 hochgezählt, wobei stratum-0 für referenzuhren wie funk, etc. gedacht ist, d.h. die uhr hat stratum-0, der server, der seine zeit von dieser bezieht -> stratum-1. wenn PC1 also stratum-1 liefern soll, muss seine zeitquelle stratum-0 haben.
du musst also der local clock auf NTP1 ein stratum von 0 geben. kann aber sein, dass ntpd das nicht zulässt.
-j
Guten Morgen,
und wie mach ich das genau auf NTP1? Ist sicher in der ntp.conf festzulegen, irgendwie, oder? :)
und wie mach ich das genau auf NTP1? Ist sicher in der ntp.conf festzulegen, irgendwie, oder? :)
sicher, das hast du doch schon selbst rausgefunden:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 0
# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
LOCAL(0) .LCL. 0 l 12 64 1 0.000 0.000 0.008
-j
Hmm... also das haben wir jetzt auf NTP1 gemacht. Jetzt steht bei ntpq -p auf PC1 als refid nur .INIT.
PC1:
remote refid st t when poll reach delay offset jitter
================================================== ============================
136.1.255.27 .INIT. 16 u 15 16 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 2 l 19 64 17 0.000 0.000 0.001
PC2:
remote refid st t when poll reach delay offset jitter
================================================== ============================
10.1.1.100 LOCAL(0) 3 u 1 16 3 0.922 -341123 6.903
LOCAL(0) LOCAL(0) 2 l 63 64 7 0.000 0.000 0.001
EDIT: jetzt hat er sie. Aber irgendwie synchronisiert er zu Anfang immer nicht. Wie lange sollte es dauern, nachdem NTPD auf NTP1, PC1 und PC2 neu gestartet wurden, bis derartige Zeitunterschiede angeglichen werden?
EDIT:
Ach verdammt, sie synchronisieren sich einfach nicht. Oder manchmal. Oder doch... aber derart sporadisch, daß man sich da einfach nicht drauf verlassen kann. Und das Offset geht rauf und runter und rauf und runter. Manchmal sind die Uhren synchron, beim nächsten Neustart des NTP Daemons wieder nicht mehr, dann dauert es wieder ewig, bis er sich angeglichen hat... ach man... ich hab schon wieder 'nen Hals! :(
EDIT:
ich finde einfach kein Muster in den von mir vorgenommenen Einstellungen. Die eigentlichen Aufgaben der verschiedenen Einstellungsmöglichkeiten sind mir soweit klar. Jedoch scheinen sie keinerlei Auswirkungen auf die Stabilität der Synchronisierung zu haben. Mal synchronisiert sich der PC1 erfolgreich mit NTP1, nach dem nächsten Neustart mit den selben Einstellungen wieder nicht mehr, dann sind auf einmal die hälfte der PC2 mit PC1 synchron, PC1 weicht aber um mehrere 100ms von NTP1 ab... ich weiß nicht mehr weiter. Benötige weitere Unterstützung!
EDIT:
pfft... ich mache ein ntpd -q, um den PC1 mal richtig mit NTP1 abzugleichen, doch innerhalb weniger Sekunden ist die Zeit wieder um einige ms verschoben... ich bin hier am verzweifeln!
PC1:
remote refid st t when poll reach delay offset jitter
================================================== ============================
136.1.255.27 .INIT. 16 u 15 16 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 2 l 19 64 17 0.000 0.000 0.001
PC2:
remote refid st t when poll reach delay offset jitter
================================================== ============================
10.1.1.100 LOCAL(0) 3 u 1 16 3 0.922 -341123 6.903
LOCAL(0) LOCAL(0) 2 l 63 64 7 0.000 0.000 0.001
wieso hat LOCAL(0) stratum 2? das funktioniert nicht, da die quelle mit dem kleinsten stratum verwendet wird.
i.d.R. dauert es 15-30min bis die uhren synchron sind, unter normalen bedingungen (LAN mit geringem jitter). synchron heisst dabei, dass sie im gleichen takt laufen. bis beide uhren den gleichen wert anzeigen, können ja nach differenz stunden vergehen.
die genauigkeit ist unter normalen bedingungen im unteren 2stelligen ms-bereich zu finden, bei mir i.d.R. < 50ms (derzeit 14ms).
meine ntp-configs sind absolut einfach, keine grossen tricks:
server ntp1
server ntp2
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
ich verwende client-server, also kein broadcast o.ä.
setze am besten mal alles auf anfang zurück und konfiguriere die kette stück für stück neu beginnend mit ntp1. und nimm für den anfang defaults.
-j
Das sieht bei uns inzwischen auch etwas anders aus. Ich zeig dir das morgen aus'm Büro. Was für uns auf jeden Fall hochpriore Punkte sind:
- möglichst genaue
- permanente
- schnellst mögliche
... Synchronisierung aller Uhren im Netz. Die eingestellte absolute Uhrzeit spielt überhaupt keine Rolle. Hauptsache synchron!
edit folgt...
So, da ich letzte Woche doch andere Dinge zu tun hatte (welch Wunder, da NTP eigentlich hochprior war... *kopfschüttel*), jetzt nochmal zum aktuellen Stand. Es tut nicht! Warum auch immer. Broadcast habe ich wieder ad akta gelegt, weil es absolut nicht funktioniert hat (liegt aber an dem Treiber für das Netzwerkinterface, den wir hier nutzen - selbstentwickelt für den VME Bus, tut aber nix zur Sache), ist also gestorben.
So, also wieder Client/Server System. Ist es technisch, bzw. vom Konzept her überhaupt möglich, mit NTP mehrere Systeme in unterschiedlichen Netzen innerhalb kürzester Zeit 99,9% synchron zu bekommen? Also nicht nur, daß sie gleich schnell ticken, sondern daß sie auch nahezu (im Bereich < 10ms) die selbe Zeit haben?
Wenn nicht, wir brauchen soetwas für unser System dringend. Gibt es andere Konzepte, die diese Funktionalität (nahezu absolute Synchronizität im Bereich von < 10ms, zu erreichen innerhalb weniger Sekunden nach dem Einschalten) bieten?
Wie bringt man NTP dazu, daß es die Angleichung der Uhren in größeren Zeitsprüngen akzeptiert? Es reicht nicht aus, daß die Uhren nur mit paralleler Geschwindigkeit laufen, es ist auch unabdingbar, daß die Uhren innerhalb von wenigen Sekunden nahezu die gleiche Uhrzeit haben! Dabei sind große Zeitsprünge völlig egal. Es muss nicht langsam angeglichen werden. Sofortige Umstellung der Zeit wäre auch absolut okay für uns.
Eigenartig finde ich, daß auch der Aufruf ntpd -g die Uhr nicht sofort an den Server angleicht, was er ja eigentlich tun sollte...
Okay, ich hab's jetzt mal versucht, den NTPD mit den Optionen -A (authorisation abschalten), -x (immer slew, nie step) und -n (nicht forken, sowieso) zu starten... hmmm... Die Zeiten schwanken immer noch stark.
Ich versteh's nicht... bitte um weitere Hilfe! Das muss doch irgendwie funktionieren, oder?!
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.