NTP Server auf dem Raspberry Pi hört auf zu funktionieren

[Fallaxia]

Hi Leute,

ich habe ein seltsames Problem mit einem NTP Server, welcher auf einem Raspberry PI B+ läuft:

Anfangs läuft der Server problemlos, auch dauerhaft ohne nennenswerte Last läuft er einwandfrei.
Sowie aber Last drauf kommt, ab ca. 1000 Anfragen pro Sekunde, fangen die Probleme an.

Trotz minimaler CPU Auslastung (so um die 10%) verliert der NTPd die Verbindung zu allen Referenz Zeitquellen, die eingestellt sind. Er kann also seine eigene Zeit nicht mehr mit den Referenzen abgleichen. Beantwortet aber weiterhin alle Anfragen. Die Abweichnung wird daher immer größer und größer.
Ein Neustart hilft auch nicht. Erst wenn keine Anfragen mehr kommen, gleicht er sofort wieder die Referenz Quellen ab und funktioniert wieder. Solange bis wieder Anfragen kommen.

Ich frage mich nun, was das sein kein.
Ich habe bei Debian Wheezy sowohl das Standard NTP Paket installiert als auch mal direkt aus dem Quellcode die aktuelle Version übersetzt. Ohne Erfolg bei der Problemlösung.

Da es im Netz viele Anleitungen zum Bau eines NTP Servers mit dem RasPI gibt, scheint mein Vorhaben einen NTP Server mit Hilfe eines RasPI aufzusetzen auch nicht so abwegig.

Hat jemand eine Idee woran es liegen könnte?
Ich habe sogar den Kernel neu kompiliert und die IRQ Timerfrequenz hoch gesetzt (auf 1000 Hz) sowie die Netzwerk (UDP) Einstellungen optimiert. Auch eine USB Netzwerkkarte kam zum Einsatz um die onBoard NIC als Fehlerquelle auszuschließen. Am Ergebnis ändert das freilich nichts, nur die CPU Auslastung ist geringer.

Hat jemand eine Idee?


PS: Auf einem uralt Pentium 60 in der gleichen Umgebung, gleiche Last, funktioniert alles wunderbar.
Nur der Pentium 60 soll aus Platz- und Strom-Verbrauchsgründen einem kompakten Ersatz weichen.

 

[Hansdampf12345]

Sind einfach zu viele Anfragen pro Sekunde.

 

[Reglohln]

Ich kann zwar nicht sagen, ob es tatsächlich zu viele Anfragen sind, aber mich würde es schonmal interessieren, warum es denn überhaupt so viele Anfragen sein müssen. Offenbar steht das teil ja bei dir privat oder? Warum werden dann so viele Anfragen gesendet? Es reicht doch, wenn jedes Gerät sich max. 1x pro Tag meldet (und ohne Reboot/Neustart reicht das dicke aus) bzw. immer, wenn ein Gerät startet, fragt es die Zeit ab.

 

[Fallaxia]

Das Gerät steht bei einem Kunden und es ist ein public Stratum 1 NTP Server.
Bislang hat im Serverrack ein uralt P60 System diesen Dienst übernommen, aber das soll/muss jetzt raus.

Und da der Kunde den NTP als kostenfreien Service anbietet, möchte er verständlicherweise keinen weiteren Meinberg Lantime (den hat er für´s Firmennetz) kaufen. Ein isolierter RasPI solls richten. Man kann sicher drüber streiten, aber das führt zu nichts.

Da ich dem Kunden gegenüber ehrlich sein möchte, mag ich nicht einfach sagen: "mit dem RasPI geht das nicht, auch wenns haufenweise HowTo´s im Netz gibt die es als idealen NTP Server preisen".
Das sollte ich wenn dann (auch aus persönlichem Interesse) schon begründen können.

Und daher frage ich auch, ob vielleicht jemand ähnliche Erfahrungen gemacht hat, oder eine Erklärung für das seltsame Verhalten hat.

Zuviele Anfragen könnte passen. Nur verstehe ich nicht, wieso der NTPd bei ~10% CPU Last (>85% idle) seine Quellen nicht mehr erreicht.

ntpq -p

liefert stets ein Ergebnis zurück, der Server antwortet auf Anfragen weiterhin, ohne eine auszulassen. Aber seine Quellen fragt er nicht mehr und verliert somit die Synchronisation langsam aber sicher.

Das System reagiert flott, Konsolenbefehle werden schnell asugeführt, keine Lags oder Verzögerungen bemerkbar, Pings ohne Latenzerhöhung, eigentlich alles normal.

 

[Hansdampf12345]

Die CPU-Last ist ja, wie du sagst gering. Also kein Wunder, dass das System flott reagiert und Konsolenbefehle schnell ausgeführt werden etc.

Trotzdem kommen einfach zu viele Anfragen rein. Hab auf die Schnelle mal diese Info gefunden: http://www.meinberg.de/german/faq/faq_22.htm
10.000 Anfragen pro Sekunde bei ner professionellen Lösung. Da ist es nicht unwahrscheinlich, dass das Pi mit 1000 pro Sekunde hinsichtlich der Netzwerkkomponenten überfordert ist.

Eventuell kannst du die Anfragen vom Pi zum Zeitserver priorisieren.

 

[Reglohln]

Ok - das erklärt es dann natürlich und ich würde mich dann wohl auch nicht mit der einfachsten Begründung ohne genaue Klärung zufrieden geben

Aber warum das nun genau bei dir passiert, vermag ich leider nicht zu sagen.
Vllt kannst du ja Debug-Meldungen zwischen den Anfragen am öffentlichen NTP ausgeben lassen, um etwas Licht ins Dunkel zu bringen. Ggf. mal ein Delay einbauen, der nach jeder Anfrage an den Rasp gewartet wird.

 

[Revolution]

Liegt ggf. Auch dran das der pi keine RTC hat allein deswegen würde ich ihn schon ned als ntp laufen lassen ...

 

[mensch183]

Stratum-1 heißt, der Raspi hat lokal Hardware angeschlossen, die ihm die Zeit liefert. Was _genau_ ist denn konfiguriert? Warum befragt er als Stratum-1 überhaupt via NTP andere Server?? Ein Stratum-1 kommt dann schnell auf die Idee: "ICH bin genau. Alle anderen sind doof. Die frage ich nun gar nicht mehr, weil deren Abweichung oder Varianz zu groß ist."

Die erste zu beantwortende Frage ist: Will er oder kann er nicht mit anderen reden? Ich tippe stark auf "will nicht".

 

[Fallaxia]

Er kann nicht.
Es ist egal was für eine Zeitquelle definiert ist. Er verliert die Verbindung zu allen, sogar der lokal angeschlossenen GPS clock bzw. DCF-77 receiver. Er kommuniziert einfach nicht mehr mit seinen Quellen, lokal, wie auch remote.

Die entscheidende Frage ist: warum?
Warum beantwortet er brav ALLE Anfragen die reinkommen, keine werden verworfen, aber schafft es nicht bei seinen Quellen nach zu fragen. Da muss doch was gehörig schief gehn oder ein Bug im Code vorliegen.

Habe sowohl die reguläre als auch die Developement Version getestet, sowohl aus dem Quellcode kompiliert als auch als Debian Paket installiert. Beides hat das gleiche Ergebnis.

 

[Hansdampf12345]

Woher weißt du, dass alle Anfragen beantwortet werden?

Kannst du die Anfragen pro Sekunde limitieren?

 

[Fallaxia]

Wirshark verrät mir dass die Anfragen beantwortet werden und iptraf über die gleiche Anzahl ein, sowie ausgehender UDP Pakete mit Ziel/Quelle Port 123.
Ja, die Anfragen kann ich limitieren über die Firewall.
Ich kann einstellen, dass eine bestimmte Anzahl Pakete pro Sekunde an den PI auf Port 123 geleitet werden und der Rest an ein anderes Ziel.

Das Ding ist, es bringt nichts. Es kommt ein Zeitpunkt, da sind selbst 10 Anfragen / Sekunde schon zuviel und der ntpd Deamon muss neu gestartet werden damit er wieder was macht, oder eine Zeit in Ruhe gelassen werden.
Ziemlich kurios alles. Hab sowas noch nicht gesehen und kann es mir nicht ansatzweise erklären.

Ne halbe Stunde beantwortet er brav locker 10k Anfragen / Sekunde bei 30% CPU Load und dann plötzlich mag er die Quellen nicht mehr erreichen können. Einfach so.
Daher kann ich mir nicht vorstellen, dass es an der Anzahl der Pakete liegt. Sonst würde das Problem ja schon nach ner Minute oder so zu beobachten sein wenn die Last anliegt oder?

 

[mensch183]

Du musst dem Ding mehr Infos über seinen Zustand entlocken, dich also mit ntpdc/ntpq/whatever beschäftigen. Oben steht: "ntpq -p liefert stets ein Ergebnis" Nur welches? Auf den peer status in der allerersten Spalte des Ouputs (vgl. "tally code" die "T"-Spalte in der 3. Tabelle) schaut man doch immer zuerst, wenn irgendwas an der Verbindung zu den peers spinnt. Ohne detallierte Statusdaten und null Infos zur Konfiguration wird dir niemand weiterhelfen können.

Ich würde wohl erstmal die Konfiguration minimieren (auf eine Quelle, das lokale GPS-Ding), das Logging hochschrauben und die FAQ durchgehen. Da gibts auch ein Kapitel zum Monitoring.

 

[Hansdampf12345]

Hat zwar nicht wirklich mit deinem Fehler zu tun: http://www.heise.de/newsticker/meld...ramatische-Fehler-im-Zeit-Server-2505113.html