Es sei denn man hat zufällig einen TACM-868 rumliegen:
Spaß beiseite. – Das passt niemals. Im 200-Byte-Szenario wären wir rechnerisch bereits bei 152 Sekunden Airtime pro Minute. Vorausgesetzt, das Paketaufkommen verteilt sich linear auf die 60s. – Tut es aber nicht. – Das Paketvorkommen kommt gerne in Peaks vor. – Eine Nachricht von mehreren Nodes wiederholt, knapp hintereinander. Die Kollisionswahrscheinlichkeit steigt hier enorm an.
Aus diesem Grund war Short Slow die richtige Konsequenz. Hier bräuchte es rechnerisch bei gleichen Werten:
80 Pakete x 0,32 s/Paket = 25,6 s
Long Fast: 152 s/min
Short Slow: 25,6 s/min
Faktor ~6.
7. Der Detektiv-Moment: die Null, die keine sein dürfte
Paketverluste MHR4 (TX Drops)
Dann kam MHR4.
Ein Router, der in seiner Laufzeit (168d) bereits rund 1,7 Millionen Pakete weitergeleitet hatte. Also definitiv kein stiller Mitläufer im Mesh. Doch zwischen all diesen Zahlen stach ein Wert heraus:
num_tx_relay_canceled = 0
NULL.
Null. 1,7 Millionen Chancen – und kein einziges Mal.
Null. Statistisch ungefähr so subtil wie ein Loch im Diagramm.
Null. So null wie ein Nashorn am Meeresgrund
Null. Als hätte jemand den Zähler ausgebaut und das Loch zugeschweißt.
Null. Die Art von Null, bei der man zuerst an einen kaputten Counter glaubt.
Bei 1,7 Millionen Relays hatte MHR4 also kein einziges Mal eine geplante Weiterleitung abgebrochen, weil ein anderer Node das Paket bereits schneller weitergeleitet hatte?
Die erste Erklärung lag nahe: Vielleicht steht MHR4 einfach so dominant im Netz, dass er fast immer der Erste ist. Gute Lage, gute Verbindungen, kurze Wege – und deshalb gibt es schlicht niemanden, dem er den Vortritt lassen müsste.
Nur: Genau das Gegenteil war der Fall.
MHR4 läuft mit der Rolle ROUTER_LATE.
Und diese Rolle wartet bewusst länger als andere Router. Sie soll gerade nicht als Erste senden. Eigentlich hätte MHR4 also ständig hören müssen, wie andere Nodes das Paket bereits weiterleiten.
Trotzdem: null Cancels.
Der Grund steckt in der Rolle selbst. ROUTER_LATE sendet nicht nur spät – es sendet trotzdem. Auch dann, wenn das Paket längst von einem anderen Router weitergeleitet wurde. Das normalerweise vorgesehene Canceln einer überflüssig gewordenen Weiterleitung ist hier schlicht deaktiviert.
Damit bekam die unscheinbare Null plötzlich eine ganz andere Bedeutung:
Sie war keine Besonderheit unserer Netztopologie. Kein Zeichen dafür, dass MHR4 allen anderen Routern überlegen wäre.
Sie war eine Konfigurations-Signatur.
Und wahrscheinlich erklärt sie gleichzeitig noch ein zweites Phänomen, das wir bei MHR4 beobachten: die immer wieder vollen Sendewarteschlangen. – Die Paketverluste. Drops.
Denn während andere Nodes erkennen können, dass ihre Arbeit bereits erledigt wurde, stellt sich MHR4 hinten an, wartet geduldig – und erledigt sie danach noch einmal.
1,7 Millionen Relays. Null Cancels.
MHR4 macht keine unnötige Doppelarbeit aus Versehen.
Er wurde genau dafür konfiguriert.
Autsch.
Und bevor jetzt jemand fragt, wer auf die glorreiche Idee mit ROUTER_LATE gekommen ist: wir.
Historisch hat MHR4 die Rolle ROUTER_LATE, weil sein Standort gerade nicht für einen Router klassifiziert. Er hat aktuell keine 360° Sicht. Er ist im Nordbereich abgeschattet.
8. Was dann passiert ist
Nach dieser Erkenntnis wollten wir wissen, ob unsere Theorie auch in der Praxis trägt.
Also haben wir genau
eine Sache geändert:
MHR4 wurde testweise von ROUTER_LATE auf einen normalen
ROUTER umgestellt.
Keine neue Antenne.
Keine neue Hardware.
Kein anderes Modem-Preset.
Nur die Rolle.
Und dann kamen die nächsten Messwerte.
Die vorher regelmäßig auftretenden
TX-Drops waren mit einem Schlag weg.
Die Sendewarteschlange lief nicht mehr voll.
Genau das Verhalten, das wir nach der Analyse erwartet hatten.
Die überflüssige Doppelarbeit verschwand. Die Queue füllte sich gar nicht erst so weit.
Und damit offensichtlich auch der Druck auf die Sendewarteschlange.
Die Erklärung liegt vermutlich weniger darin, dass MHR4 plötzlich weniger Arbeit hat – sondern darin,
wann er sie erledigt.
Als ROUTER_LATE hört MHR4 zunächst lange zu und reiht seine geplanten Weiterleitungen in die Sendewarteschlange ein. Bei einem Standort mit diesem Paketaufkommen kann sich diese Queue immer weiter füllen, bis irgendwann kein Platz mehr ist: num_tx_dropped steigt.
Als normaler ROUTER wartet MHR4 nicht mehr so lange. Er sendet seine Weiterleitungen früher – die Queue bekommt gar nicht erst die Gelegenheit, sich derart aufzustauen.
Damit wurde aus einer auffälligen Null plötzlich ein ziemlich schönes Experiment:
Vorher:
ROUTER_LATE
1,7 Millionen Relays
0 Relay-Cancels
24.616 TX-Drops
Nachher:
ROUTER
TX-Drops praktisch verschwunden
Eine Konfigurationsänderung – und das Verhalten des Nodes änderte sich unmittelbar messbar.
Allerdings gab es noch einen zweiten Effekt:
Die Channel Utilization ging nach oben.
Das klingt im ersten Moment widersprüchlich. Wir verhindern unnötige Aussendungen – und trotzdem steigt die gemessene Kanalauslastung?
Aber auch das werden wir uns noch genauer ansehen. Ein Router verhält sich bei der Weiterleitung schließlich anders als ein ROUTER_LATE, insbesondere bei der Priorisierung und dem Zeitpunkt seiner Aussendungen.
Auch das passt ins Bild: MHR4 wartet nun nicht mehr im Hintergrund, sondern beteiligt sich früher und aktiver an der Weiterleitung.
Für den Moment ist die wichtigste Erkenntnis eine andere:
Die vollen Sendewarteschlangen von MHR4 waren offenbar kein unvermeidbares Ergebnis seines stark belasteten Standortes.
Sie waren zumindest zu einem erheblichen Teil
eine Folge seiner Rolle.
Und genau deshalb messen wir.
Nicht, damit Grafana noch ein paar bunte Kurven mehr hat.
Sondern damit wir Entscheidungen, die irgendwann einmal sinnvoll erschienen, später mit echten Daten wieder überprüfen können.
MHR4 darf deshalb vorerst seine Beförderung zum
ROUTER behalten.
Ob das dauerhaft die bessere Lösung ist, zeigen uns die nächsten Tage.
Diesmal müssen wir nicht raten.
Diesmal haben wir Zähler.
9. Und noch eine Zahl zum Schluss
Es gab da noch die Frage: Wie viele Nodes sieht MHR4 eigentlich. – Nun leider ist auf den NRF Boards der Speicher begrenzt. 80 ist maximal. Diesen Wert haben wir konstant. Alte Nodes werden konstant heraus rolliert und neue übernehmen.
Aber: TSM sitzt in direkter Sicht zu MHR4 – TSM ist auf einem Raspberry Pi aufgebaut, und unterliegt dieser Begrenzung nicht. – Die Konfiguration sieht 700 Knoten aktuell maximal vor. – Diese Slots sind derzeit alle Belegt. – 285 werden als Online markiert.
Auch kann man in unserem Dashboard (
https://dashboard.meshhessen.de) die Anzahl der Nodes nachsehen. Wir haben aktuell 653 Aktive Nodes in 24h, 579 nehmen aktiv Teil. (Stand 17.08.26) – es ist also durchaus davon auszugehen, dass MHR4 in der Größenordnung 300-400 Nodes bedient.
Cheers 73
-TSM aka Gerrit
Wie viel arbeiten Meshhessen-router.pdf (Größe: 674,05 KB / Downloads: 1)
