Cl0wn_K1ll3r Geschrieben 1. April 2009 Geschrieben 1. April 2009 Hallo zusammen, bei uns in der Firma werden 2 DCF77 Funkuhren der Firma Hopf eingesetzt. Diese sind mit einer jeweils eigenen Dach-Antenne verbunden, mit der das Zeitsignal aus Frankfurt empfangen wird. In den Funkuhren ist jeweils eine NTP-LAN-Server Karte eingebaut, welche mittels WEB-Oberfläche (wahlweise auch Telnet, SSH, kleines Frontdisplay) konfiguriert werden kann. Problem: Der ingebaute NTP-Server hat allerdings das Problem, dass er alle paar stunden, mindestens 1 mal am Tag, seinen primären "NTP System peer" - also die Funkuhr selbst mit der IP 127.127.38.0 - nicht mehr akzeptiert, bzw. auf 0.0.0.0 setzt. Während dieser Zeit läuft der NTP-Service auf Stratum 16 und einige unserer auf den NTP-Dienst angewiesenen Server spucken Fehlermeldungen aus. Es ist zwar kein wirklich kritischer Fehler, stören tut er aber trotzdem. Das selbe Phänomen tritt auf, wenn man den NTP-Service manuell neu startet - während dieser Zeit (ca. 50 Sekunden) ist der NTP-Service down, bzw. auf Stratum 16. Folgende Dinge habe ich schon ausprobiert, allerdings erfolglos: - neueste Firmware aufspielen - sämtliche logging-Möglichkeiten an und ausgeschaltet (in der Vermutung dass irgendein Speicher volläuft und deshalb der NTP-Servide restartet wird) - sämtliche anderen NTP-Peers (Zeitserver im Internet) aus der Konfiguration herausgenommen. - NTP-Stratum im Freilaufmodus (wenn das Funksignal nicht empfangen werden kann und die Funkuhr auf internen Quarz-Betrieb umstellt) auf 1 gestellt Natürlich könnte ich das Gerät an den technischen Kundendienst des Herstellers schicken, aber ich bezweifle das dies eine Besserung bringt, da wir erst vor wenigen Monaten eine neue Funkuhr, neuerer Bauart, installiert haben, bei der aber genau das gleiche Phänomen auftaucht. Hat von euch vielleicht einer ne Idee woran das liegen könnte? Ist im NTP-Protokoll vielleicht was festgelegt, dass ab und zu die Peers gewechselt werden sollen, auch wenn es nur einen möglichen Peer gibt? Vielen Dank schonmal im Vorraus, Martin :-) Zitieren
VaNaTiC Geschrieben 2. April 2009 Geschrieben 2. April 2009 DCF77 Funkuhren der Firma Hopf Setzen wir auch öfters ein. ... eine NTP-LAN-Server Karte eingebaut, ... Kenne ich leider nicht. Haben eine eigene Implementierung. ... seinen primären "NTP System peer" - also die Funkuhr selbst mit der IP 127.127.38.0 - nicht mehr akzeptiert, bzw. auf 0.0.0.0 setzt. Woher wisst ihr das? Wegen den Fehlermeldungen der anderen Rechner? Während dieser Zeit läuft der NTP-Service auf Stratum 16 und ... Das selbe Phänomen tritt auf, wenn man den NTP-Service manuell neu startet - während dieser Zeit (ca. 50 Sekunden) ist der NTP-Service down, bzw. auf Stratum 16. Stratum 16 ist doch immer, wenn der NTP nicht weiss an welcher Stelle in der Reihe er sitzt, oder seh ich das falsch? Folgende Dinge habe ich schon ausprobiert, allerdings erfolglos: Was sagt denn der Hopf-Support dazu? Hast Du schonmal eine andere Zugriffsebene an die Hopf probiert? Nicht das die DCF77 das Problem ist. Ist im NTP-Protokoll vielleicht was festgelegt, dass ab und zu die Peers gewechselt werden sollen, auch wenn es nur einen möglichen Peer gibt? Ich hab selber SNTP und ein paar wenige Features aus NTP als Client und Server implementiert, aber das ist mir beim Lesen der RFCs, ... nicht unter gekommen. Zitieren
Cl0wn_K1ll3r Geschrieben 6. April 2009 Autor Geschrieben 6. April 2009 Die Fehlermeldungen kamen per SMTP-Fehlermeldung und lauten folgendermaßen: Device Type: 727100 Hostname: hopf727x IP-Address: 10.232.88.210 Timestamp: 18.03.2009 11:22:01 UTC Notification: NTP System peer change Details: Systempeer changed from 127.127.38.0 to 0.0.0.0 und etwas später dann so: Device Type: 727100 Hostname: hopf727x IP-Address: 10.232.88.210 Timestamp: 18.03.2009 11:22:48 UTC Notification: NTP System peer change Details: Systempeer changed from 0.0.0.0 to 127.127.38.0 --------------------------------------------------------------------- Diese paar Sekunden reichen aus um auf einigen Servern Fehlermeldungen zu erzeugen. Kritisch ist das in keinster Weise, denn jede noch so ungenaue Quarz-Uhr wird einen Ausfall der Synchronisationsquelle für ein paar Sekunden überbrücken können, ohne gleich neben der Spur zu laufen. Es ist einfach nur unschön, zumal da auch nen Großrechner mit dranhängt... Während dieser Zeit läuft der Server auf Stratum 16. Kurios ist, dass eine Funkuhr im Online-Interface auch meldet, dass die "Device-Uptime" mit jedem NTP System Peer Change auf 0 gesetzt wird. Die andere (neuere) Funkuhr ändert zwar ihre NTP System Peers, aber die Device-Uptime bleibt länger stabil...aber auch selten mehr als 10 Tage. Der technische Hopf-Support meint, dass es entweder an einer Schwankung der Versorungsspannung liegen könnte (bei einem reduntanten Stromnetz mit USV ist das quasi unmöglich). Ansonsten bliebe nur die Option die Dinger einzuschicken...was wenig Sinn machen wird, wenn bereits 2 Funkuhren das selbe Problem haben...:old Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.