Einzelner NTP-Server im isolierten Netzwerk

Ich habe zwei Linux-Maschinen (A und B) in einem isolierten Netzwerk. Sie müssen zeitsynchronisiert sein. Maschine A wird intermittierend mit Strom versorgt und muss die Zeit bedienen, da sie an eine maßgebliche Zeitquelle (GPS) angeschlossen ist. Maschine B wird nur mit Strom versorgt, wenn Maschine A mit Strom versorgt wird. Es handelt sich jedoch um ein eingebettetes Linux-Gerät, dessen Energiezustand sich häufig ändert. Keiner der Computer hat Zugriff auf andere Systeme. Es ist ein geschlossenes Netzwerk.

Ich verstehe, dass dies für NTP eine ziemlich große Aufgabe ist, da NTP normalerweise Kontakt mit mehreren Servern erwartet. Ich habe Probleme damit, dass dies auf Maschine B ordnungsgemäß funktioniert. Maschine A wird problemlos mit dem GPS synchronisiert, und Maschine B kann Maschine A erreichen und sogar Zeitabfragen durchführen, aber Maschine A ist nicht vertrauenswürdig (möglicherweise von selbst?). Nach einer vollen Stunde, in der Maschine A in Betrieb war, änderte sich dies plötzlich und Maschine B arbeitete. Wenn jedoch Maschine A ausfällt (und damit Maschine B), kann Maschine B erneut keine gute Zeitsynchronisation finden.

Hier sind einige ntpdate-Informationen. Bitte beachten Sie, dass selbst wenn die Schicht von Maschine A 1 ist, der Vorgang am Ende mit derselben Ausgabe fehlschlägt.

10.10.10.1: Server gelöscht: Schichten zu hoch
Server 10.10.10.1, Port 123
Schicht 16, Präzision -19, Sprung 11, Vertrauen 000
refid [10.10.10.1], Verzögerung 0.02614, Dispersion 0.00000
übertragen 4, in Filter 4
Referenzzeit: 00000000.00000000 Do, 7. Februar 2036 6: 28: 16.000
Ursprungszeitstempel: d3a9bdc4.27ebb350 Do, 12. Juli 2012 21: 19: 00.155
Sendezeitstempel: bc17c803.b42dfffe Sa, 1. Januar 2000 0: 25: 39.703
Filterverzögerung: 0,02625 0,02614 0,02618 0,02625 
         0,00000 0,00000 0,00000 0,00000 
Filterversatz: 39544160 39544160 39544160 39544160
         0,000000 0,000000 0,000000 0,000000
Verzögerung 0,02614, Dispersion 0,00000
Offset 395441600.451568

 1 Jan 00:25:39 ntpdate [677]: Kein für die Synchronisation geeigneter Server gefunden

Ich vermute, dass Maschine A sich einfach nicht für die Servierzeit vertraut. Nach 51 Minuten (möglicherweise früher, ich weiß nicht) Betriebszeit und Synchronisierung der Uhr mit GPS begann Maschine A, die Zeit korrekt zu bedienen, und Maschine B nahm sie auf. Ich brauche das früher. Wie wenn möglich innerhalb von Sekunden.

Mit den folgenden Konfigurationen (und viel Warten) gelingt es schließlich.

Maschine A ntp.conf:

Server 127.127.28.0 bevorzugen echte Minpoll 4 Maxpoll 4
Fudge 127.127.28.0 Schicht 1 Zeit1 0.420 Refid GPS 

Maschine B ntp.conf:

Server 10.10.10.1 bevorzugen echte Minpoll 4 Maxpoll 4

ntpq -c Peers auf Maschine B ohne Zeitkorrektur:

     Remote Refid st t, wenn die Abfrage den Verzögerungsoffset-Jitter erreicht
================================================== ============================
 10.10.10.1 .STEP. 16 u 9 16 0 0,000 0,000 0,000

ntp1 -c-Peers auf Maschine B mit guter Zeitkorrektur:

     Remote Refid st t, wenn die Abfrage den Verzögerungsoffset-Jitter erreicht
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0,669 2,597 1,808

Nun stellt sich die Frage: Wie kann ich Machine A schnell selbst vertrauen lassen?

Einige Debug-Ausgaben von Maschine A vor und nach Maschine B entscheiden, dass Maschine A gut genug ist, um verwendet zu werden.

Vor..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 event, no_sys_peer,
version = "ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)",
Prozessor = "armv7l", System = "Linux / 2.6.35.14", Sprung = 11, Schicht = 2,
Genauigkeit = -19, Rootdelay = 0,000, Rootdisp = 44,537, Refid = SHM (0),
Reftime = d3ab0053.43b44780 Fr, 13. Juli 2012 20: 15: 15.264,
clock = d3ab0062.e7e03154 Fr, 13. Juli 2012 20: 15: 30.905, peer = 34819, tc = 4,
Mintc = 3, Offset = 0,000, Frequenz = 0,000, sys_jitter = 3,853,
clk_jitter = 36.492, clk_wander = 0.000

nach...

~ # ntpq -c rv
associd = 0 status = 0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version = "ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)",
Prozessor = "armv7l", System = "Linux / 2.6.35.14", Sprung = 00, Schicht = 2,
Genauigkeit = -19, Rootdelay = 0,000, Rootdisp = 41,278, refid = SHM (0),
Reftime = d3ab0063.43b37856 Fr, 13. Juli 2012 20: 15: 31.264,
clock = d3ab006d.9ee53ec2 Fr, 13. Juli 2012 20: 15: 41.620, peer = 34819, tc = 4,
Mintc = 3, Offset = 0,000, Frequenz = 43,896, sys_jitter = 0,762,
clk_jitter = 36.953, clk_wander = 0.000

NTP sollte gut funktionieren. Schauen Sie sich einige der Optionen für eine schnelle Synchronisierung beim Start an. Sehen Sie sich die Optionen burstund iburstfür das System B an. Sehen Sie sich die trueOption für die GPS-Uhrquelle an.

Verwenden Sie auf beiden Systemen die Hardwareuhr als Sicherungszeitquelle. Stellen Sie ein System mit höherer Schicht B ein. Etwa Folgendes sollte funktionieren:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Beobachten Sie die Ausgabe von, um ntpq -c peerszu sehen, wann Sie eine vertrauenswürdige Taktquelle erhalten. Normalerweise ntpmöchte eine Reihe von Antworten von einer vertrauenswürdigen Zeitquelle, bevor sie ihr vertraut. Dies wird durch das erste Zeichen in jeder Zeile angezeigt.

Während NTP mehr Quellen mag, sollte eine ungerade Anzahl von Zeitquellen innerhalb einer Schichtstufe gut funktionieren. Da Sie nur zwei Server und eine GPS-Uhr haben, sollte die Priorität (Schicht) der Quellen von GPS, Uhr auf Server A, Uhr auf Server B erhöht werden. Durch Erhöhen der Schicht zwischen jeder um drei oder vier Ebenen wird sichergestellt, dass die Prioritäten eingehalten werden.

BEARBEITEN: Wenn Sie den Busybox-NTP-Server auf Server A haben, kann es sich lohnen, das vollständige NTP-Serverpaket zu installieren. Das Verständnis der Vorgänge mit Server A sollte einen großen Beitrag zur Lösung Ihres Problems leisten. Sie benötigen dort mindestens eine vertrauenswürdige Zeitquelle, bevor Server B ihr vertrauen kann. Wenn ntpq -c peerses nicht funktioniert, können Sie es versuchen ntpdc peers. Mit beiden Befehlen können Sie andere Hosts abfragen. Ein peerstatsProtokoll könnte ebenfalls nützlich sein.

Verwenden Sie auf Server B ntpclient, wie dokumentiert, und dokumentieren Sie , was auf dem Server passiert

Die Uhren sollten ziemlich nahe an der richtigen Zeit sein, wenn die Server nicht lange ausgefallen sind. Wenn Sie die beiden Systeme synchronisieren müssen, sollte dies ausreichen. Das GPS wird die Zeit schließlich mit der realen Welt synchronisieren.

'ntpd -q' wird schnell synchronisiert, aber beendet (ntpdate-Verhalten). Es muss ein ntpdBefehl ohne die Option quit folgen, um eine kontinuierliche Synchronisierung zu ermöglichen.

EDIT2: Ich habe meinen Server überprüft und festgestellt, dass einer der Server um eine Sekunde ausgeschaltet war. Während ich das reparierte, spielte ich mit den Einstellungen. iburstbekommt einen Server sehr schnell vertrauenswürdig. truestellte sicher, dass dem Uhrentreiber vertraut wurde, wenn nicht mehrere andere vertrauenswürdige Quellen vorhanden waren. Es dauerte etwas mehr als eine Minute, bis die Uhr lokal vertrauenswürdig war und aus der Ferne vertrauenswürdig war.

Beim Testen sollten Sie in der Lage sein, den ntpdProzess nach der Synchronisierung neu zu starten und zu testen, wie schnell die Einstellungen funktionieren. In dem oben genannten Fall muss Server B möglicherweise neu gestartet werden, um zu testen, wie schnell er synchronisiert wird. Bei der Überwachung von ntpdÄnderungen verwende ich eine Zeile wie:

while ntpq -c peers localhost; do sleep 10; done

Der Hostname und die Ruhezeit werden nach Bedarf angepasst. In einigen Fällen verkette ich zwei oder mehr ntpqBefehlszeilen in der Schleife. Dabei verwende ich einen Echo- und / oder Datumsbefehl, um anzuzeigen, wo sich Datensätze ändern.