Netzauslastung & Massnahmen

Guten Tag APZ68

Da du Zustände in der Region Bern erwähnst, könnten wir (HB9BG) uns angesprochen fühlen. Gerne nehme ich daher zu ein paar Punkten Stellung:

  • Ab wann Repeater auf einem Mapper “ausgrauen” ist uns bisher nicht bekannt. Unsere Advert-Intervalle sind entweder auf 25 Stunden oder auf 23 Stunden eingestellt. Dies, um die Adverts zu immer leicht verschobenen Tageszeiten auszusenden und so innert ein paar Tagen möglichst alle Benutzer zu erreichen, unabhängig von deren Einschaltzeiten. Zudem gewichten wir eine moderate Belastung des Netzes durch Adverts höher als die korrekte Funktion von nicht betriebsrelevanten Netzelementen (z.B. mapper, analyzer, pingbots etc.).

  • Die Versorgung von Repeatern mit Updates erfordert immer einen physischen Besuch am Standort. Die Updates werden zuerst an einem oder zwei sehr gut erreichbaren Repeatern eingespielt und über ein paar Tage die Stabilität beobachtet. Danach folgen die etwas weiter entfernten Repeater, welche eine durchschnittliche Anreisezeit von min. 30 Min. beanspruchen. Es gab auch schon Firmwareversionen, welche wir lieber nicht eingespielt hätten, weil sie sonderbare Effekte bezüglich der Stabilität zeigten… Daraus lernt man und wartet jeweils etwas länger.

  • Die zwei Transalp-Repeater stellen bezüglich der Updates eine Ausnahme dar. Es sei uns bitte gestattet, diese Repeater auf 3700 m Höhe nur dann zu besuchen, wenn dies unbedingt erforderlich- und auch mit vernünftigem Aufwand machbar ist. Diese Repeater wurden bewusst als “Satelliten” konzipiert und haben die Umweltbedingungen am Aufbauort seit ihrer Inbetriebnahme bisher exzellent überstanden. Das Konzept hat sich somit bewährt. Updates sind hier zweitrangig und können nur dann eingeplant werden, wenn der primäre Grund des Besuches genügend Zeit für diese sekundäre Aufgabe zulässt. Sollte der Betrieb des Netzes infolge einer zu alten Firmware einmal nachhaLtig gestört werden, so steht jederzeit die Option der Abschaltung bereit. (Allerdings sehen wir hier noch andere Optimierungsmöglichkeiten, welche eher im Nutzerverhalten zu suchen sind).

  • Auch wir beobachten ab und zu unbekannte Neighbours. Allerdings hat sich mir der Sinn von mobilen- und temporären Repeatern" bisher noch nicht erschlossen. Vielleicht benötige ich hierzu ein Update?

Weiterhin viel Spass bei der Nutzung von MeshCore.

L.G. Christoph

3 Likes

Hallo Florian

Das verstehe ich nicht. Ich habe am rx/tx-delay nichts verändert und beide dind auf 0.0. Welche Einstellungen hast du konkret gemacht und kannst du mir die Wirkung so erklären, dass auch meine feuchte Zündschnur Funken sprüht?

Naja, Ich hab mich in den Blogs eingelesen und festgestellt das manche Benutzer bei übermässigen Paketfehler die Empfangs- und Sendeintervalle raufsetzen, um theoretischen eben die Paketfehler runter zu fahren. Sprich die Zeitfenster für Empfang und senden werden länger, was in diesem Intervall ankommt wird nicht verarbeitet, soweit ich das verstanden habe. Sollte eben theoretisch die Qualität der Sendungen erhöhen. Ich habe diese Einstellung aber erst seit vier Tagen am laufen, und heute ist die Paketfehlerrate bei 25 %. Ich weiss ehrlich gesagt nicht was dieser Wert bedeutet, im Vergleich zu anderen Repeater. Ich muss diese Woche aber trotzdem klettern um ihn zu updaten, dann verpass ich dem Repeater noch eine andere Antenne und Position, wird sich dann zeigen.

Konkret:

set tx delay 1.0 (Default 0.5)

set rx delay 0.5 (Default 0.0)

Aber eben das ist nur testweise, bis jetzt ist die Fehlerrate von 33% auf 25% runtergekommen, kann ziemlich sicher auch mit einem Hardware/Positionsupdate erreicht werden.

@chix Stimmt das so? Ich hab das grad getestet und ich konnte auch ohne Default Region Scope meinen Repeater managen und auch auf Telemetry zugreifen. Die Nachrichten ohne Scope wurden auch korrekt nicht weitergeleitet, also das sollte funktioneren. Companion und Repeater sind auf neuster Firmware.

Ob das aber auch über 1+ Hops funktionert, kann ich nicht sagen. Ich kann mir vorstellen, dass das nur funktioniert, wenn diese Repeater * zulassen.

Hab das auch hier so erwähnt → Einstellungen repeater - #2 by zh_fox

1 Like

Hallo Florian

Der Befehl lautet richtigerweise:

set txdelay 1.0

set rxdelay 0.5

(zumindest in der Version 1.15, vielleicht war es früher anders).

Herzliche Grüsse

Beni

1 Like

Alles was “Direct” ist und nicht über Hops läuft ist anscheinend nicht von den Region Scope Settings betroffen. Ich nehme mal an darum klappt das bei dir im Moment ohne den Default Refion Scope zu setzen.

Zufälligerweise bin ich auf dieses Dokument der Niederländischen Community gestossen, das so ziemlich alle Massnahmen gegen die Netzauslastung beschreibt. Was wir hier noch diskutieren, setzen sie bereits um.

Zusammengefasst:

  • Firmware Version: Minimum 1.15
  • SF: 7
  • CR: 5
  • Advert interval: Minimum 50h (!)
  • Zero hop advert interval: 4h
  • Bots: Keine (z.B. Ping Bots)
  • Region Scoping: Nur getagte Nachrichten werden repeated (*: flood deny)
  • Path hash mode: 1 (2-Byte)
  • Loop detect: Minimal
  • Duty Cycle: 10%
4 Likes

Ich denke vorallem den * entfernen wird viel bringen. Man wird quasi für Region scope gezwungen. Was eine gute Sache ist :slight_smile:

4 Likes

Sollen wir wirklich zu Insellösungen resp Abschottungen migrieren?
Wenn wir in dieser Richtung gehen killen wir den Gedanken eines internationalen Netzes.

Wenn schon sollten die Repeater mit den Regionen und rx-/txDelay “einschränken”.
Auch wäre es schön, wenn die Companions nur in den eigenen (Gross-)Regionen funken würden. Dies allerings müssen erst die User dahinter begreifen.

Nur so ein paar Gedanken eines ziemlich neuen, noch enthusiastischen MC-Benutzers

2 Likes

Hallo Urs

Grossregionen können problemlos eingestellt werden. Die weitreichenden Repeater sind einfach auch entsprechend einzustellen. Dafür braucht es aber eine schweizweite Koordination. Also technisch und organisatorisch machbar. Aber wollen wir das wirklich realisieren? Das böse Erwachen kommt m.E. leider spätestens dann, wenn Kreti und Pleti seine Spielzeuge darauf ansetzt - ob mit Absicht oder aus anderen Gründen sei dahingestellt.

4 Likes

Ich sehe vorallem den Nutzen darin, dass der generelle Flood Traffic abnimmt und innerhalb Regionen bleibt. Man kann ja immer noch mit Region Europe weit kommen. So hätte man beide ‘Welten’ bedient

3 Likes

Interessant, dass sie Europa mit “eu” benennen und wir mit “europe” …

1 Like

Chix: könntest Du bitte die empfohlenen Einstellungen irgendwo Fix Posten, so, dass man sie nur noch eigeben kann.

Am besten die von Paul vorgeschlagenen 3 Versionen für unten, mitte, oben.

2 Likes

Mein erster Repeater ist nun etwas mehr als 24h auf dem Dach, dabei habe ich als default region scope “ch” festgelegt und den Flood für Nachrichten ohne Scope deaktiviert.

Der Repeater funktionert super, aber anfangs war ich verwirrt, wieso er meine Nachrichten zwar zuverlässig raus-repeatet, aber keine Nachrichten von anderen Leuten weiter-repeatet. Ganz einfach, praktisch niemand nutzt die Region Scopes auf seinem/ihrem Companion! Von den paar Dutzend öffentlichen Nachrichten, die ich angeschaut habe, waren nur einige wenige mit Region Scope…

Ich denke, auf den Repeatern den Flood für Nachrichten ohne Scope zu deaktivieren, wäre ein guter Schritt in die Zukunft. Der einzige Nachteil (den ich sehe) dabei ist, dass neue User zwingend ein Scope hinzufügen müssen, und sonst nicht mit dem Mesh kommunizieren können. Gleichzeitig zwingt das aber auch, etwas Recherche anstellen zu müssen, was ja etwas gutes ist. Evt. lernen Nutzer dadurch generell mehr über wie MeshCore funktioniert und benutzen das Mesh etwas zurückhaltender (siehe Ping Spam etc).

Passend dazu habe ich soeben von jemandem aus Schottland im offiziellen MeshCore Discord Server erfahren, dass sie auf ihren Repeatern bereits den Flood von Nachrichten ohne Scope deaktiviert haben. Für sie hat sich das sehr positiv auf das Mesh ausgewirkt.

5 Likes

Mit dieser Beobachtung bist du nicht allein und der Bericht aus Schottland ist absolut zutreffend.

Die Entwickler haben ihre Software mit dem Schwerpunkt zur Übermittlung von Direktnachrichten ausgelegt. Von Beginn weg haben sie darauf hingewiesen, dass Flood-Nachrichten ‘teuer’ sind, weil sie sehr viel Airtime konsumieren. Flood-Nachrichten werden halt, wenn die Repeater gut platziert sind, schnell mal über 20 und mehr Hops weitergereicht. Mit dem Analyzer lässt sich das gut beobachten.
Um diese ‘wilde’ Ausbreitung zu begrenzen, also um Airtime frei zu machen → den Stau auf dem Netz zu reduzieren, wurde Region Scope eingeführt. Das wird nun schrittweise, mit jedem Firmwarerelease, weiter implementiert (z.B. Default Region Scope beim Compagnion und multi-byte path hashes bei den Repeatern).
Ich denke, dass in einigen Monaten alle Repeater umgestellt sein werden (vielleicht wird das auch mit einem Firmwarerelease erfolgen) und danach nur noch mit Region-Scope gearbeitet werden kann.

Solche Bilder (08.05.2026, empfangen in Burgdorf BE) werden hoffentlich zusehends verschwinden.

4 Likes

@Stupfihuus Die Internet-Anbindung würd auch das Problem mit den jetzt Isolierten Repeatern lösen.

Ich gehe mal davon aus, dass da zuerst jemand die Software schreiben müsste… Aber die könnte ja auch so ausgelegt sein, dass sie bei Internet Ausfall als Reserve in den Repeater Modus wechselt.

Edit: Der Post, auf den ich hier Antworte, wurde gelöscht. Ich lasse ihn aber trotzdem noch da, ich denke die Punkte sind relevant und klären auf.

Meine Antwort

@Stupfihuus Netzauslastung & Massnahmen - #38

Ich bin mir ziemlich sicher, dein Post wurde mit einem KI Chatbot verfasst und nicht faktisch geprüft. Du vermischt hier MeshCore mit Meshtastic. Das passiert der KI, weil MeshCore noch extrem neu ist im Vergleich zu Meshtastic, habe ich selber auch schon gemerkt. Wenn du KI zu MeshCore befragen möchtest, musst du ihr eine Quelle geben, die sie brauchen kann, wie zum Beispiel das offizielle MeshCore GitHub Repository.

Das habe ich mit Gemini Pro (der KI Chatbot von Google) gemacht und es einen Faktencheck deines Posts machen lassen. Hier die Antwort, die ich nach meinem Wissen geprüft habe (Gebt bitte Bescheid, falls etwas nicht stimmt):

Zu Punkt 1 & 2: Raumserver als MQTT/Internet-Gateways zur Reduktion von Hops

  • FALSCH: MeshCore nutzt kein Internet und kein MQTT (ausser “Observer”). Das System ist explizit als dezentrales Off-Grid-Netzwerk konzipiert, das keine zentralen Server oder Internetverbindungen benötigt.
  • Ein “Room Server” in MeshCore hat absolut nichts mit Internet-Gateways zu tun. Ein Raumserver ist in MeshCore ein einfaches BBS (Bulletin Board System) zum Teilen von Beiträgen über LoRa-Funk.
  • Das “Hop Limit” muss in MeshCore nicht künstlich niedrig gehalten werden, um das Netz zu retten. Die Firmware unterstützt intern bis zu 64 Hops. Da Direktnachrichten pfadbasiert geroutet werden, ersticken sie das Netz nicht. (Nur Gruppenkanäle nutzen standardmäßig Flood-Routing).

Zu Punkt 3: Intelligentes Filtern (Gating) via Internet

  • FALSCH: Da es keine Internet-Spiegelung gibt, gibt es auch dieses beschriebene Filtern/Deduplizieren über eine IP-Ebene nicht.
  • Administratoren von MeshCore-Repeatern können jedoch eigene Regeln aufstellen, um Flood-Traffic (z. B. auf öffentlichen Kanälen) ab einem bestimmten Hop-Limit zu blockieren (Befehl: set flood.max).

Zu Punkt 4: Der “Store & Forward” Ansatz (Raumserver)

  • KORREKT (aber nur über RF): Der Text erfasst die Grundfunktion eines MeshCore-Raumservers richtig, allerdings findet dies rein über Funk statt, nicht über das Internet. Raumserver speichern den Nachrichtenverlauf lokal auf dem Gerät. Umherstreifende Nutzer können sich später mit dem Raumserver verbinden und erhalten dann die bis zu 32 zuletzt ungelesenen Nachrichten zugestellt. Das Prinzip ähnelt einem E-Mail-Server.
  • Wichtig: Es wird sogar davon abgeraten, die Repeater-Funktion auf einem Raumserver zu aktivieren (set repeat on), da einem solchen Gerät die vollständigen Routing- und Fernwartungsfunktionen eines echten Repeaters fehlen.

Zu “Was müsste die Community tun?”

  • Der Vorschlag, von “Router” in “Client”-Modus zu wechseln, ist ein klassischer Meshtastic-Rat. In MeshCore flasht man für Endgeräte ohnehin die “Companion”-Firmware, die von Natur aus niemals Nachrichten wiederholt.
  • Internet-Uplinks an Raumservern (wie in Punkt 2 gefordert) existieren im MeshCore-Ökosystem nicht.

Zu guter Letzt, hier die Beschreibung eines MeshCore Room Servers aus der offiziellen Dokumentation:

1.2.5. Room Server

A room server is a simple BBS server for sharing posts. T-Deck devices running MeshCore firmware or a BLE Companion client connected to a smartphone running the MeshCore app can connect to a room server.

Room servers store message history on them and push the stored messages to users. Room servers allow roaming users to come back later and retrieve message history. With channels, messages are either received when it’s sent, or not received and missed if the channel user is out of range. Room servers are different and more like email servers where you can come back later and get your emails from your mail server.

A room server can be remotely administered using a T-Deck running the MeshCore firmware with remote administration features unlocked, or from a BLE Companion client connected to a smartphone running the MeshCore app.

When a client logs into a room server, the client will receive the previously 32 unseen messages.

Although room server can also repeat with the command line command set repeat on, it is not recommended nor encouraged. A room server with repeat set to on lacks the full set of repeater and remote administration features that are only available in the repeater firmware.

The recommendation is to run repeater and room server on separate devices for the best experience.

4 Likes

Drei hochaktuelle Dinge zum Thema Netzauslastung und Massnahmen, die ich gerne mit euch teilen möchte!


1. Massnahmen gegen Advert-Spam direkt in der Firmware (zukünftig)

Hier eine spannende Nachricht von Liam Cottle aus dem MeshCore Discord Server zu Massnahmen gegen die Netzauslastung:

Liam Cottle

I had some discussions on this the other night [welche Massnahmen gegen den Advert Spam getroffen würden] , and my opinion is to implement TTL/max hops for advert packets at the packet level, and set some sort of default, like 3 or 5. that way adverts don’t by default travel 30+ hops everytime they flood. also prob increase the default flood advert interval now that we have the ability to discover neighbours on demand on both companions and repeaters

Das würde sicherlich immens helfen!

Zusätzlich könnte auch bald eine max Flood Einstellung spezifisch für Adverts kommen, mit der ein Repeater nur Adverts, die ein gewisses maximum an Hops nicht überschreiten, weiterleitet.


2. Abschalten des Floods von Nachrichten ohne Region Scope

Dazu habe ich folgende pragmatische Lösung gehört, von einem Community Member auf dem Discord:

Es würde Sinn machen, dass vor allem die “Back Bone” Repeater, die sehr viel Traffic haben, den Flood für Nachrichten ohne Region Scope deaktivieren, aber dafür lokalere Repeater den Flood zulassen. Dadurch gehen die Nachrichten neuer Nutzer zwar raus, sodass neue Nutzer auch eine Antwort erhalten können (wie optimalerweise “Konfiguriere eine Region!”), aber gleichzeitig Fluten sie damit nicht das ganze Mesh!

Zusätzlich dazu können wir erwarten, dass in einem zukünftigen Update der App die Nachrichten in öffentlichen Chats mit Region Scope gekennzeichnet werden, sodass neue Nutzer direkt sehen können, dass sie eines verwenden sollten.
Wegen der technischen Implementation von Region Scopes können diese zwar nicht direkt angezeigt werden, wenn der Nutzer sie nicht hinzugefügt hat (es wird ein Hash verwendet). Aber durch die “Scan Regions” Funktion können diese erlernt werden. Die Idee ist also, dass wenn eine Nachricht eine Region hat, die der Nutzer nicht hinzugefügt hat, ihn das z.B. über ein Symbol zum erfassen und Nutzung der Regions führen soll.

Disclaimer: Für diese Features gibt es keine exakte Timeline, sie sind aber alle auf dem Schirm der Entwickler. Wir müssen uns sicherlich etwas gedulden.


3. Region-Konfiguration auf unseren Repeater heute

Zu guter Letzt, Folgendes ist mir auch noch in den Sinn gekommen:
Bei konfigurieren der Regionen auf den Repeater sollte man darauf achten, dass man auch wirklich die richtigen Regions konfiguriert. Also meines Erachtens nach sollte ein Repeater in Zürich ja eben nicht die Regionen wie ch-it und ch-fr haben, sondern nur ch, ch-de und europe, oder?


Gebt gerne eure Meinungen zu diesen Punkten durch!

5 Likes

Edit: Der Post, auf den ich hier Antworte, wurde gelöscht.

Meine Antwort

Aufgrund dieser Karte muss ich aber sage, dass das keinen Sinn macht. Wieso sollte mein Repeater in Zürich jetzt Nachrichten, die für die Romandie ch-fr gemeint sind, weiter “flooden”? Weil wenn alle in Zürich auf ihren Repeater diese Region hinzufügen, dann ist ja damit rein gar nichts erreicht, die Nachricht breitet sich genau gleich aus als wenn sie ch hätte…

Nachtrag: Ich denke die einzigen, die vielleicht beides konfigurieren sollten, sind die genau im Grenzbereich.