Gluon NTP Polling Intervall

Hi Freifunk Community,

habe schon versucht etwas darüber in der offiziellen Gluon Dokumentation (https://goo.gl/Ry22kN) herauszufinden und habe ebenfalls das Forum nach weiteren Informationen durchstöbert. Beides jedoch ohne Erfolg.

Ich habe heute meinen Freifunk Router wider zum Laufen bekommen und ein wenig Troubleshooting auf der Firewall dadurch durchführen müssen. Dabei habe ich bemerkt, dass der Router respektive das System externe NTP Server anspricht. Da ich über einen eigenen NTP Server verfüge, habe ich schnell die Konfiguration adjustiert.

Beim genaueren hinsehen fällt jedoch auf, dass der NTP Server sehr häufig angefragt wird (ca. alle 2 Minuten).
Für meinen Geschmack verursacht das permanetene NTP Polling ein sehr hohes Grundrauschen, was meiner Meinung nach nicht unbedingt sein muss (wenn es einen trifftigen Grund dafür gibt, OK, dann aber erstmal her damit :smile: ). Selbst Enterprise Systeme fragen Standardmäßig alle 60 Minuten ab.

Gibt es eine Möglichkeit, dass Polling Intervall zu adjustieren, sprich von 2 Minuten auf 30 Minuten zu erhöhen oder lässt sich so eine Funktion auf Dauer einbauen?

Besten Dank schonmal im Voraus.

Nur alle zwei Minuten? NTP soll ja eigentlch zur Zeitsynchronisation dienen, d. h. alle Uhren sollten im Millisekundenbereich gleich laufen — zwei Minuten als Abfrageintervall halte ich da schon für ziemlich selten? IIRC sollte ntp doch im Sekundentakt sich abgleichen?

Ja, das hat damals (mag schon 10 Jahre) zum Bann von ganzen Router-Familen/Firmwares durch ntp.org geführt.
Also bei „kommerziellen“ SoHo-Geräten.

Sekundentakt ?? halt mal halt mal… also typisch ist das Pollingintervall initial 64s arbeitet sich dann aber je nach Qualitaet der Strecke und der Uhren runter in der Häufigkeit bis auf 1024s. Je schlechter der lokale Takt, um so besser sollte die Anbindung sein.
Entscheidend ist der Gleichlauf der Uhren und reproduzierbarkeit der ping Zeiten.

Allerdings ist das in der Anfangsphase bevor ntpd sich mit einem Server synchronisiert hat, deutlich mehr. Dann ist es wirklich alle 2 Sekunden oder so. Auf meinem Linux zur Fritzbox ist er damit aber nach maximal einer Minute fertig und dann geht es mit der Minute weiter.

Die sonst ueblichen Kommandos hat man nicht zur Verfuegung und ich greenhorn habe den NTP Traffic ums Verrecken nicht finden koennen mit batctl td - also das passende if. Also habe ich dem ntpd mit strace ueber die Schulter geschaut:

ps|grep ntp

22821 root 1388 S /usr/sbin/ntpd -n -l -p 2.pool.ntp.org
31557 root 1384 S grep ntp

strace -I 1 -p22821


strace: attach: ptrace(PTRACE_ATTACH, …):


write(2, „ntpd: reply from 2001:418:3ff::1“…, 74) = 74
gettimeofday({1475608072, 56691}, NULL) = 0
poll([{fd=3, events=POLLIN}], 1, 33000

so siehts am Schluss häufig aus und man kann die 33000ms Timeout immer direkt ablesen.
Aber der Wert variiert halt manchmal. Das Umfeld ist nun mal ziemlich variabel. Ich halte jetzt mal ein Auge darauf, wohin es sich noch entwickelt.

Also 2min sind normal und vllt sogar eher besser.

1 Like

bei mir sinds immer noch 32-34s. Vermute das wird auch nicht besser werden. Liegt vllt auch am WR841ND. Ich kenne VMs auf bestimmten Systemen, die musste ich mit minpoll=maxpoll=4 festnageln, weil deren virtuelle clock mehr ein wackelpudding ist. Oder anderes Beispiel: matschige Clock eines CPU Boards finden, in dem man den ntpd immer fuer eine Weile an eine fixe CPU bindet, bis man die findet, bei der er die Synchronisation verliert. Also da bekommt Zeitqualitaet wirklich eine Bedeutung.
NTP ist nicht nur irgendwo eine Zeit abholen. Wenn man sich eine GPS Clock ins RZ stellt und ueber 40Gbit vernetzt ist, kann man sich eine Stunde haeufig leisten, wenn die lokale Clock es hergibt.

Ich hatte mich auch schon gefragt, wieso überhaupt NTP, wenn die Benutzer davon ohnehin nichts mitbekommen. Jede Stunden ntpdate koennte reichen. Aber ich habe den Verdacht, die meshing Protokolle haben evtl da hoehere Anforderungen.

Wieviel NTP Percentage habe die Supernodes so ?? So hoch wird das Grundrauschen durch NTP auch nicht sein…

2 Likes

Hallo Zusammen,

vielen Dank für die Antworten. Ich erkenne allerdings keine wirklichen Abhängigkeiten, oder habe ich etwas überlesen. Wird es in zukünftigen eine Option zum anpassen des NTP Polling Intervalls geben?

Ansonsten hat sich das Thema ja eigentlich erledigt, da das Verhalten anscheinend „normal“ ist. :-).
Besten Dank für die hilfreichen Antworten.

der typische ntpd in diesem Umfeld ist nur ein Bestandteil von Busybox. Normalerweise braucht man Optionen zum Anpassen eher nicht, es sei denn es ist sowieso was ziemlich wackelig. Dann wuerde man das Intervall aber nicht vergroessern, sondern verkleinern, damit noch was geht. Wenn die Automatik es dann nicht stemmt, dann sollte man ohnehin ueber andere Massnahmen nachdenken. Der Usage von dem Kommando sagt nichts ueber solche Moeglichkeiten.

Wir haben im Moment bei den kleinen Geräten ohnehin reichlich PlatzMangel :wink:, aber wenn das kein Problem ist, kann man auch den Standard ISC ntpd nehmen - vermute ich mal. Im opkg list finde ich ihn jedenfalls schon mal.

1 Like

auch zu meiner eigene Erbauung schaue ich mir das hier auch mal an:

Ich Danke für die Antworten und schaue mir die Einträge unter den Links einmal an.

Moin.

Da ich gerade in der c`t (24/2016) über das Thema Multi-WAN-Bau lese, hier eine Aussage dazu:

… erhöht aber die Grundlast. So verursacht ein 1-Sekunden-Ping in einem Monat rund 150 Megabyte Traffic.

Finde ich schon heftig die Datenmenge.

Gruß

Quelle: c't | Heise Magazine (Der Artikel ist kostenpflichtig, weil aktuell)

In Zeiten von Domains, die nach wie vor fast 1GB/24h an Hintergrundtraffic haben (ohne einen einzigen User auf einem Knoten): Kaum der Rede Wert, anderes Kleinvieh macht deutlich mehr Mist.

1 Like