Was passiert eigentlich, wenn: 'Mal schnell ein 'Ping' abgesetzt wird...'

[Paul_Simmen]

‘Ping’ ist, neben ‘Guten Tag’, ‘Morgähn’, ‘Gute Nacht’ und einigen anderen Floskeln, die in MeshCore wohl am meistübertragene ‘Payload’.

Was bedeutet eigentlich ‘Ping’? Ping ist ein Messwert für die Geschwindigkeit (in ms) einer Internetverbindung. Genauer gesagt, misst Ping die Zeit, die ein Datensignal von deinem Computer zu einem Server und zurück braucht.

Die allgemeine Strategie von MeshCore zur Übertagung von Paketen lautet: „Wenn immer möglich direkte Pfade! Flood-Methode nur als Ausweichlösung“.

Jedes Paket wird entweder im Flood- oder im Direktmodus gesendet. Um Ressourcen zu schonen, nutzt die Pfadfindung dafür die normalen Pakete, z.B. Nachrichten.

Wenn also A, keinen Pfad zu B hat, wird beim Senden einer Nachricht der Flood-Modus verwendet.

Wird B gefunden, erhält B die Nachricht und den Pfad ebendieser in einem Paket. Im Kontext von Nachrichten wird eine Bestätigung (ACK) mit dem Pfad dann an A zurückgesendet.

Zurück zum ‘Ping’! Die Nachricht mit dem Text “Ping” wird in ‘Channel’s’, d.h. im ‘Flood’ - Modus ins Mesh abgesetzt. ‘Channels’ können die Nachrichten nicht anders, als im Flood-Modus absetzen. (Flood bedeutet Überschwemmung durch Wasser, welches über die Ufer tritt).

Soweit so gut! Hier sehen wir den Weg der Nachricht ‘ping’, welche von der Station HV abgesetzt wurde. HV sieht nach dem Absetzen der Nachricht, dass diese von einem oder mehreren Repeatern empfangen und verteilt worden ist. Was HV auf seinem Companion nicht sieht, ist der wirkliche Weg seiner Nachricht und 12 der Repeater (einige mehrfach), welche die Nachricht empfangen und weitergeleitet haben.

Schlussendlich ist HV’s Nachricht von einem ‘Empfänger mit automatischer Antwort an den Sender’ empfangen worden.

Dieser ‘Bot’ macht, was er zur Freude seines Eigentümers, tun soll: Er sendet eine Nachricht an HV zurück.

Dabei quittiert der ‘Bot’ die letzten Repeater, welche er im Paket mit der Nachricht von HV empfangen hat. Er gibt seiner Antwort an HV lediglich die Repeater 36, 3e, 34, 0b, 96 als Weg mit. Nach dem letzten Repeater ist für das Paket wieder der Flood-Modus angesagt.

Die Nachricht legt also erneut einen Weg vom Bodensee zum Genfersee - mit einigen Umwegen - zurück.

Kommen wir zurück, zur ‘Überschwemmung durch Wasser, das über die Ufer tritt’. Der Bach überläuft, wenn die Wassermassen im Verhältnis zum Bachbett oder zum Rohrdurchmesser (dort wo er gefasst wird) zu gross sind und es deswegen nicht mehr normal fliessen kann.

Unser Mesh kennt auch einen ‘Rohrdurchmesser’ - die Bandbreite. Die Pakete teilen sich diese auf. Sind mehr Pakete unterwegs als Bandbreite zur Verfügung steht, entsteht ein Engpass, die Pakete kollidieren und werden dann einfach nicht mehr übertragen.

Und ja, wenn man einfach, weil es schön ist und man gehört sein will - also ohne Notwendigkeit - Ping’s ‘en masse’ absetzt, muss man sich im Klaren sein, dass genau der zuletzt abgesetzt Ping derjenige sein kann, der den Bach zum Überlaufen bringt.

Brauchen wir MeshCore doch dafür, für was es ausgelegt ist: Nachrichtenübertragung auf direkten Pfaden!

Bin gespannt auf eine angeregte Diskussion zum Thema.

Lieber Gruss, Paul

(Die Daten und Grafiken wurden mit dem MeshCore - Analyzer am 15.02.2026 durch mehrere Observer-Stationen erfasst und aufgezeichnet.)

[ssozonoff]

Hi,

So I have one of the ping Bots running here in Geneva and I more than happy to turn it off, maybe it could be scoped to our region as a first step.

However there is basically no traffic at the moment in our area so any new potential Meshcore user who joins the mesh is pretty much left with the impression that nothing is happening. (same for Meshtastic users who are thinking of migrating to Meshcore only to see that its dead around here).

Some of use know that the reality is the mesh is just getting started and we are trying to build it out. We had some traffic here from our Swiss German counterparts with our last repeater install which at least made it look alive but now all that traffic is gone. Either because of region codes which have been implemented somewhere along the line or then a repeater which has fallen.

I guess what I am trying to say is that you are 100% correct but if we optimise too early we run the risk of not having anyone because all interest is lost. There is nothing more exciting then setting up your first companion and starting to receive some traffic (and to be able to respond). We need to be able to build up some momentum.

This is just my thoughts,

Serge

[HB9HVS]

Guten Abend Paul
Ja da sprichts Du ein wichtiges Thema an. Auf DMR, dem digitalen Amateurfunknetz auf VHF/UHF haben sich 2 Stationen auf dem weltweiten Kanal unterhalten, bis sich eine weitere Station eingeschaltet hat und gefragt hat, ob sich die beiden Kollegen eigentlich bewusst seien, dass sie durch ihr Tun weltweit über tausend Repeater aktivieren.

Sich bewusst sein ,was man mit seinem Tun auslöst, ist wahrscheinlich das Wichtigste auch bei MeshCore. Hier wird ein verantwortungsvoller Einsatz der Regionen ein erster Schritt sein. Ob es schlussendlich gelingt, die automatisierten Bots zu reduzieren wird sich zeigen. Jedenfalls scheint die Versuchung gross, am Abend nach der Arbeit regelmässig ein “ping” abzusetzen und zu sehen, wie “weit” man kommt. Dass man dabei des Netz flutet (ein schöner Ausdruck!) ist vielen gar nicht bewusst.
Ich bin ebenfalls gespannt auf die weitere Diskussion.
LG Heinz

[ssozonoff]

IMHO Until there is actually any volume of traffic this wont be the main problem. The main problem will be adoption and getting some of the MT crew to move to MC to help grow the mesh. I am sure you have more traffic in the Swiss German region but we dont have that issue here.

[HB9HVS]

Just wait a month or two until there is a repeater in the area of Mt. Tendre. The net will then “explode” as in the Swiss German Region. Yesterday I had to switch off the “Public” channel, because I get hundreds of messages in 24 hours.

By the way: Mt. Tendre in the Col du Marchairuz-Region seems to be a good spot to link VD an GE to the net!

[TM-n]

Morning

Das Problem sind nicht die Pings, sondern die unlimitierte Anzahl Hops. Ein Blick auf die Discover-Map zeigt nach 1 Tag Messages von Genua, Heidelberg bis Salzburg an. An die Vernunft der User zu appelieren, reicht wohl nicht aus. Das geht nur über technische Limiten.

Mein Repeater TM-20 “hört” bereits alle 4 Sekunden ein Packet. Vor genau 2 Monaten waren es noch all 8 Sekunden. Gleicher Standort, dieselben 6 Neighbours.

Ob da die Regions etwas Linderung schaffen, werden wir noch sehen.

73 de TM

[Paul_Simmen]

Guten Tag

Danke für deine Posts hier und zum anderen Thema. Ich erlaube mir, in ‚meiner‘ Standardsprache zu schreiben. Die Übersetzung überlasse ich irgend einer ‚Translate‘-App.

Ich verstehe deine Sicht auf unsere ‚Themen’. Es muss für dich komisch klingen, wenn wir schreiben, dass wir uns Sorgen wegen der Überlastung des Netzes machen, während bei dir in der Region ch-fr Stille herrscht.

Aller Anfang ist schwer. Wir haben das vor einem Jahr festgestellt als wir erste Versuche und Erfahrungen mit MeshCore im Dreieck Biel - Solothurn - Burgdorf machten. Weil wir, jeder an seinem Ort, Interesse und Spass an der Sache hatten, mit Repeatern und Standorten experimentierten, breitete sich das Netz ziemlich rasch in Richtung Osten aus.

MeshCore ist offensichtlich auch für Funkamateure interessant. Das siehst du an den vielen HB9-ern, im Netz und auch hier im Blog. Die im Raum Belp-Gürbetal beheimatete Gruppe HB9BG hat früh Wissen und persönliches Engagement für den Netzausbau eingebracht (z.B. Transalp-Verbindung). Christoph @HB9DTZ teilt auch immer wieder in lehrreichen Beiträgen sein Wissen mit uns. So lernen wir viel voneinander - kombinieren in Versuchen Theorie und Praxis.

Warum ich dir das schreibe? Ich möchte dir damit Mut machen zur Pionierarbeit! Nur wenn du selber Repeater planst, baust, geeignete Orte suchst und sie dort platzierst, machst du Fehler und ziehst daraus wichtige Schlüsse. Schlüsse, welche dir beim nächsten Versuch Erfolg bringen. Plötzlich wirst du auch auf andere Menschen treffen, welche das gleiche tun wie du. Du wirst sehen, das ist der Moment wo das Netz zu wachsen beginnt.

Erste Schritte könnten vielleicht sein:

Mit Hilfe der Karte im MesCore Analyzer zu schauen, welche Knoten in deiner Nähe sind und dich mit deinen Repeatern mit diesen zu verbinden.

Vielleicht hast du einen Kollegen, mit dem du in Genf ein kleines Stadtnetz aufbauen kannst. Mit drei vier Repeatern experimentieren und versuchen gute Verbindungen (SNR > 1) herzustellen.

‚Der Weg entsteht, indem man ihn geht!‘ diese Weisheit gilt auch für das Hobby mit den Miniatursendern. Dazu braucht es auch Harnäckigkeit, wie du in den Beiträgen von @Bullit lesen kannst.

Lieber Gruss, Paul

[Martin]

@TM-n

Das Problem sind nicht die Pings, sondern die unlimitierte Anzahl Hops.

Vielleicht sollte man nicht (nur) mit regions arbeiten, sondern ev:

• die Anzahl hops auf einem repeater limitieren können (ich repeate nur, wenn es kleiner als zB 6 hops sind)
• wenn “genügend” neighbour-repeater das Signal weitergeleitet haben, es selber nicht mehr repeaten. Wenn mein repeater nach einem minimalen time-out weniger als zB 3 repeats gehört hat, wird es weitergeleitet.

Dies wären Konfiugrations-Parameter für jeden repeater Betreiber.

Weiss jemand übrigens, wie das mit dem Pfad geht? Wenn ein Pfad -aa-bb-cc-dd- ist, leitet dann cc das Paket nur weiter, wenn es von bb gehört wurde, oder einfach, weil er sein Kürzel cc irgendwo in der Liste findet?

mfg Martin

[Paul_Simmen]

Guten Tag Heinz

Vielen Dank für deinen Input! Er zeigt einmal mehr, dass auch andernorts immer wieder an den Basics und am technischen Verständnis gearbeitet werden muss.

Gerade deswegen sind die Beiträge aus der Feder der OM’s sehr wertvoll. Ich glaube, das wir, einhergehend mit dem grösser werden des Netzes, hier auch technische Informationen in Alltagssprache bereitstellen müssen.

Es braucht ein Wissen um die Philosophie, welche die Grundlage für die Firmware ist, damit die Hardware richtig eingesetzt und konfiguriert wird. Schlussendlich geht es auch hier nicht ohne die Kenntnis der physikalischen Zusammenhänge.

Alle, welche bereit sind, sich mit diesen Basics auseinander zu setzen werden ihre ‘Gerätchen’ richtig nutzen und werden m.E. lange an der Sache Freude haben. Der Rest wird wahrscheinlich nach kurzer Zeit wieder aus dem Netz verschwinden.

Lieber Gruss, Paul

[stef]

Hallo Martin,

Die Limitierung der Hops für “flooded” welche du ansprichst ist bereits möglich.

# im Repeater CLI überprüfen 
>get flood.max
>16  # bei meinen Repeatern 16, default 64
# setzen
>set flood.max 16

Bei mir im Einflussbereich meiner und einiger Repeater ohne die Restriktion, sieht die Verteilung übrigens wie folgt aus. Die Verteilung hat sich etwas verschoben seit ich dies anwende aber meine Repeater verwerfen damit nicht massiv Traffic.

Zusätzlich ermöglicht der spezielle Repeater EVO Release eine Reduktion der Adverts basierend auf der Anzahl Hops. Die Wahrscheinlichkeit das Adverts forwarded werden, wird dabei kleiner je mehr Hops bereits im Pfad stehen.

Beschreibung : Probabilistic Flood Forwarding for Advertisement Packets

Die Frage bezüglich der Weiterleitung von “directed” Messages wenn ein Hop übersprungen wird, habe ich mir auch bereits gestellt. Generell habe ich jedoch das Gefühl dass “directed” Messages bei einer Pfadlänge von >3 Hops im Moment kaum mehr funktionieren. Dafür mache ich die momentane Last im Netz verantwortlich und hoffe dass sich dies mit der Segmentierung durch Regionen wieder verbessert.

Die Anzahl Messages pro Minute im Tagesverlauf sieht bei mir wie folgt aus:

Im Peak über 45 Messages pro Minute, bei durchschnittlich ca 300ms pro Message besteht eine hohe Chance für Kollisionen. Adverts da riesig konsumieren überdurchschnittlich viel Airtime. Pong Responses gefüllt mit redundantem Nonsens Text und vielen Emojis übrigens auch!

• Eine “flooded” Message und das sind ja alle Channel Messages, hat eine grosse Chancen anzukommen da jeweils über viele Pfade geflutet wird, ein Paketverlust auf einem Pfad wird kompensiert.
• Eine “directed “Message jedoch nicht. Eine Kollision an einem Repeater im Pfad führt bereits dazu dass die Message ihr Ziel nicht erreicht.