Quality of Service (QoS) Implementierung für MeshCore

Dieser Artikel beschreibt den aktuellen Zustand des MeshCore Netzwerks in der Region Stuttgart, welche Ursachen es für die Überlastung gibt und wie ein stabiler Zustand wiederhergestellt werden kann.

TL;DR

Die Firmware kann unter https://mesh.q60.de/qos/repeater-firmware/ heruntergeladen werden.

Diese Firmware enthält einen dynamischen Filter, der sicherstellt, dass das Netz nicht durch unwichtige Pakete (z. B. Adverts) überlastet wird und dadurch wichtige Pakete (z. B. Nachrichten in Channels) nicht mehr zuverlässig übertragen werden.

Quellcode: https://github.com/slisson/MeshCore/tree/qos

Entwicklung der letzten Monate

Den Anfang machten die ersten Repeater im August 2025. Während man im Oktober/November noch jeden neuen Repeater feierte, war zum Jahreswechsel ein relativ stabiles Netz entstanden. Zu dem Zeitpunkt war das Netz aber noch eine Insel und hatte bis auf kurzzeitige Überreichweiten keine Verbindung zu den anderen Regionen. Südlich entwickelte sich ein Netzwerk entlang der Alpen (München, Österreich, Schweiz, Italien). Im Nordosten eines entlang der Elbe (Hamburg, Harz, Magdeburg, Leipzig).

Im Januar hat sich das Stuttgarter Netz weiter Richtung Schwarzwald ausgebreitet und ist schließlich mit dem Schweizer Netz zusammengewachsen. Während das Netz vorher stetig an Stabilität zugenommen hat, kommen Nachrichten jetzt immer unzuverlässiger ans Ziel.

Ursachen

Zunächst ist festzuhalten, dass ein Mesh Netzwerk, in dem jede Nachricht im gesamten Netzwerk weitergeleitet wird, nicht beliebig groß werden kann.

Flood vs. Direct Routing

Ein wesentlicher Unterschied von MeshCore im Vergleich zu z. B. Meshtastic ist die Unterstützung für direktes Routing von Nachrichten zwischen zwei Teilnehmern. Wenn dem Absender der Pfad zu dem Empfänger bekannt ist, kann er diesen für die Nachricht vorgeben und verhindert damit die Verbreitung außerhalb dieses Pfades. In nachfolgender Tabelle ist zu sehen, welcher Anteil der Nachrichten diese Art von Routing nutzt.
Routing Anzahl Relativer Anteil
Flood 34324 98.77%
Direct 7719 1.23%

Zu beachten ist, dass diese Daten nur von einer einem einzelnen Observer gesammelt wurden. Damit ist keine Aussage darüber möglich wie viele der Nachrichten im gesamten Netzwerk direktes Routing nutzen, weil die meisten davon eben nicht bei diesem Observer ankommen.

Für die Lösung des Problems spielt dies allerdings keine Rolle. Entscheidend ist immer nur die lokale Auslastung des Funkkanals.

Bei einem Anteil von lediglich 1.23 % können Nachrichten mit direktem Routing vom QoS Algorithmus ausgeschlossen werden und einfach immer weitergeleitet werden. Dies ist allein deswegen schon sinnvoll, weil die Nachricht ja explizit eine Weiterleitung durch den entsprechenden Repeater vorsieht und auf keinem anderen Pfad das Ziel erreichen kann.

Arten von Flood Nachrichten

Möchte man die Menge der Flood Nachrichten reduzieren, sollte man zuerst diejenigen Nachrichten Filtern, bei denen es zu keiner spürbaren Einschränkung der Funktionalität kommt.

Die folgende Tabelle listet die verschiedenen Typen von Flood Nachrichten auf und welchen Anteil an der gesamten Menge der Flood Nachrichten ausmachen.

Art Anzahl Relativer Anteil
GroupText 8277 24.11%
TextMessage 7719 22.49%
Advert 5672 16.52%
Response 5048 14.71%
Request 3060 8.92%
AnonRequest 2001 5.83%
Path 2028 5.91%
Ack 503 1.47%
GroupData 16 0.05%

Repeater Verwaltung

29.5 % der Nachrichten sind vom Typ Request, AnonRequest oder Response. Diese Nachrichten werden für die Remote Verwaltung der Repeater genutzt. Einige Daten werden auch als TextMessage übertragen. Der Anteil von 22.49 % enthält also nicht nur Text Nachrichten zwischen zwei Nutzern, sondern auch Daten zur Repeater Verwaltung.

Wenn man berücksichtigt, dass Nachrichten zwischen zwei Nutzern in der Regel mit direktem Routing übertragen werden sollten, dann ist davon auszugehen, dass der überwiegende Teil diese TextMessages Nachrichten von Repeatern sind.

Schaut man sich die Absender und Empfänger Hashes der TextMessages an, fällt auf, dass 2161 Nachrichten vom gleichen Absender stammen. Dies entspricht 6.3 % der gesamten Flood Nachrichten. Über eine Woche gerechnet entspricht dies wohl nicht zufällig einer Nachricht jede 5 Minuten. Hier scheint jemand in der Schweiz automatisiert den Zustand seines Repeaters abzufragen, welche dann mit einer Flood Nachricht antwortet.

Ob manuelle Remote Verwaltung oder automatisierte Statusabfrage, beides halte ich für legitime Anwendungsfälle. Diese Nachrichten sollten aber nicht durch das gesamte Netzwerk weitergeleitet werden, sondern lokal begrenzt werden. Eine Nachricht alle 5 Minuten ist noch weit davon entfernt den lokalen Funkkanal auszulasten.

In der Regel wird der Betreiber eines Repeaters sich in unmittelbarer Nähe zu diesem Aufhalten und kann diesen entweder direkt oder über wenige Hops erreichen. Bei diesen Arten von Nachrichten gibt es das größte Einsparpotenzial.

Channels

Nachrichten in Channels sind wichtigste Art von Nachrichten. Diese können nur über Flood Routing übertragen werden und man weiß nicht, ob die Nachricht überhaupt angekommen ist. Wenn eine Nachricht bei einem Nutzer nicht ankommt, ist diese verloren und eine sinnvolle Beteiligung an der Diskussion ist nicht mehr möglich. Aber nicht jeder Channel ist für jeden Nutzer relevant.

In der nachfolgenden Tabelle sind die Channels mit der Anzahl der Nachrichten dargestellt. Die Angaben zu den Hops helfen dabei zu verstehen, ob es sich um einen Channel aus der eigenen Region handelt oder um einen aus einer anderen Region.

Hash Name Anzahl Nachrichten Relativer Anteil Min Hops Ø Hops Max Hops
d9 #test 2018 24.38% 1 6.3 20
11 Public 766 9.25% 1 7.8 22
53 411 4.97% 2 6.6 25
d9 264 3.19% 6 14.3 31
5e Italia 261 3.15% 5 9.6 21
f3 247 2.98% 2 5.1 16
20 #chtest 184 2.22% 4 9.2 16
2e #prove 179 2.16% 5 8.9 23
e7 #switzerland 174 2.10% 3 8.7 14
bd #stuttgart 149 1.80% 1 2.8 9
81 132 1.59% 1 5.3 19
10 126 1.52% 2 5 63
28 #ping 125 1.51% 1 8.6 21
e0 124 1.50% 4 10.1 23
37 #stw 122 1.47% 10 15.1 25
df 120 1.45% 1 3.8 27
4c 113 1.37% 9 15.8 29
11 108 1.30% 6 15.2 31
98 93 1.12% 4 9.5 24
ca #qrv 91 1.10% 2 6.7 14
0a 91 1.10% 5 10.1 30
5e 76 0.92% 7 15.1 40
06 Varazze 72 0.87% 5 10 16
4b 67 0.81% 0 2.1 6
f6 65 0.79% 4 9.7 23
83 Ticino 63 0.76% 5 9.1 23
08 59 0.71% 7 12.4 30
68 54 0.65% 1 2.8 16
62 #wetter 49 0.59% 2 7.3 17
a2 48 0.58% 5 10 29
50 #flachwitze 47 0.57% 2 10.9 17
7e 45 0.54% 6 11.2 26
e7 43 0.52% 8 15.8 33
1d 33 0.40% 6 9.9 27
20 33 0.40% 9 16.5 27
da 32 0.39% 7 10.7 16
f2 31 0.37% 8 14.9 28
5a #test-bw 31 0.37% 1 3.6 7
28 30 0.36% 1 12 23
7d 30 0.36% 1 4.3 16
4e 29 0.35% 6 10.2 19
c1 29 0.35% 6 10 18
05 29 0.35% 6 11.5 23
2e 28 0.34% 9 16.2 27
91 #warnings 26 0.31% 8 11.7 17
37 25 0.30% 7 20.5 33
70 25 0.30% 6 10.2 21
02 25 0.30% 5 9 16
bf #basel 24 0.29% 5 8.3 15
35 #hambot 24 0.29% 6 9 13
4f 24 0.29% 2 4.7 11
ca 23 0.28% 6 16.3 24
94 21 0.25% 3 7.3 23
64 #zuerich 21 0.25% 5 8.4 12
fb #austria 21 0.25% 6 8.6 13
06 #mctechtalk 21 0.25% 1 3.8 8
79 19 0.23% 4 7.8 17
1e #suedbaden 18 0.22% 5 7.3 11
0d #freiburg 17 0.21% 6 7.9 11
50 17 0.21% 1 9.1 26
38 17 0.21% 9 12.6 19
4b 16 0.19% 2 7.6 18
35 News 16 0.19% 6 8.1 16
e8 16 0.19% 3 9.6 17
be 15 0.18% 2 5.1 15
6b 14 0.17% 9 11.4 14
46 14 0.17% 6 10.1 16
d7 14 0.17% 1 4.7 14
ee 14 0.17% 3 5.6 13
ec 14 0.17% 6 10 18
2a 14 0.17% 2 6.7 18
bd 13 0.16% 2 10.7 22
Sonstige 828 10.00% 0 12.4 61

Auffällig sind die diversen Testkanäle (#test, #chtest, #prove, #ping, #stw, #test-bw). Diese machen einen Anteil von 32.1 % an den gesamten GroupText Nachrichten aus. In den Kanälen antworten diverse Bots auf ping Nachrichten.

Man kann darüber streiten, ob solche Nachrichten eine legitime Nutzung des Netzwerks sind und ob man Nachrichten von Bots filtern sollte. Es gibt allerdings noch die vielen privaten Kanäle, deren Inhalte unbekannt sind und deswegen gar nicht bezüglich ihres Nutzens bewertet werden können.

Grundsätzlich halte ich Ordnungsrufe an einzelne Netzwerkteilnehmer nicht für Zielführend. Das Netzwerk muss sicherstellen, dass eine Überlastung in einem Kanal nicht die Kommunikation in einem anderen Kanal beeinträchtigt.

Adverts

Adverts machen mittlerweile nur noch 16.5 % vom Flood aufkommen aus. Viele Repeater Betreiber sind dem Aufruf gefolgt die Advert Intervale zu vergrößern. Kürzlich wurde in der Firmware auch die maximale Zeit zwischen automatischen Flood Adverts von 2 auf 7 Tagen erhöht. Teilweise wird auch eine Custom Firmware betrieben, die Flood Adverts nicht weiterleitet.

Auch wenn Adverts von Repeatern nicht direkt für das Funktionieren des Netzwerks notwendig sind, so sorgt eine leere Karte doch für Verwunderung bei neuen Nutzern. Aber auch für die Planung des Netzausbaus ist es wichtig zu wissen, wo noch zu schließende Lücken vorhanden sind.

Wegen ihrer Redundanz gehören die Adverts sicher zu den Nachrichten, die am stärksten eingeschränkt werden können, aber nicht bis auf 0.

Node Typ Anzahl Relativer Anteil
Repeater 4402 77.62%
Companion 774 13.65%
Room 489 8.62%
Sensor 6 0.11%

Einen Unterschied macht auch die Art des Nodes. Companions senden nur einen Advert, wenn dies manuell ausgelöst wird. Außerdem sind diese technisch notwendig. Nur wenn zwei Companions sich gegenseitig zu ihren Kontakten hinzugefügt haben, ist ein direkter Austausch von Nachrichten möglich.

Path und Ack

Diese Nachrichten Arten dienen eher der Entlastung des Netzwerks und sollten deshalb Priorität vor anderen Arten haben.

Path Nachrichten enthalten den Pfad über den eine Flood Nachricht empfangen wurde, sodass für die nächste Nachricht direktes Routing verwendet werdne kann.

Ack bestätigt den Empfang von Direktnachrichten. Wenn diese Bestätigung nicht ankommt, wird die ursprüngliche Nachricht nochmal versendet und erzeugt damit zusätzliche Last.

Lösungsansätze

Die bisherigen Lösungsversuche sind eher als erste Hilfe Maßnahme zu verstehen, die vorübergehend die Stabilität wiederherstellen sollen, aber langfristig keine befriedigenden Ergebnisse liefern.

Manuelle Ursachenforschung

Hierzu gehört das manuelle identifizieren von Quellen hoher Last und kontaktieren des Verursachers. Dies wirkt, wenn überhaupt, nur für kurze Zeit, bis die nächste Störquelle auftaucht.

Hop Limit

Die Begrenzung der Hops basiert auf der Annahme, dass sich diese proportional zur Reichweite verhält. Regional Kommunikation ist wichtiger als große Reichweiten. Allerdings können 8 Hops bis nach Italien reichen oder auch nur bis ans andere Ende der Stadt.

Bei Meshtastic ist häufig zu beobachten, dass man Nachrichten aus Frankreich empfängt, aber mit jemandem eine Straße weiter keine Kommunikation möglich ist. Aus gutem Grund hat MeshCore praktisch kein Hop limit.

Regionen

Als Alternative zu dem ungeeigneten Hop Limit wurden in MeshCore Regionen eingeführt, um die Reichweite einzuschränken. So kann innerhalb regionaler Netzwerke eine zuverlässige Zustellung erreicht werden, ohne dass Nachrichten sich unbegrenzt ausbreiten.

Zurzeit sind aber nur wenige Repeater mit Regionen konfiguriert. Außerdem muss jeder Benutzer für jeden Kanal die entsprechende Region konfigurieren. Für den größten Teil der Nachrichten ist es auch gar nicht möglich eine Region anzugeben. Dies ist nur für GroupText Nachrichten möglich, also für die 24.1 % der Flood Nachrichten.

Statische Filterung

Wie bereits erwähnt gibt es bereits Custom Firmwares, welche Repeater Adverts filtern. Dies ist eine extreme erste Hilfe Maßnahme und auf Dauer nicht optimal.

Zum Beispiel ändert sich die Auslastung abhängig von der Tageszeit. Tagsüber und insbesondere Abends gibt es viele Nachrichten in Kanälen und zwischen Benutzern. Nachts wären hingegen Kapazitäten für Adverts frei.

Dynamische Filterung

Eine dynamische Filterung ist wahrscheinlich die beste Lösung. Diese passt die Filterregeln an die tatsächliche Auslastung an. So kann schnell auf neue Störquellen reagiert und diese lokal isoliert werden. Ziel ist es die vorhandene Kanalkapazität optimal zu nutzen. Das heißt so viele Nachrichten wie möglich weiterzuleiten, soweit die Stabilität dadurch nicht beeinträchtigt wird.

Custom Firmware mit QoS Implementierung

In den letzten Tagen habe ich die Firmware um einen solchen Algorithmus erweitert, der nur eine begrenzte Menge der empfangenen Nachrichten weiterleitet.

Die wesentliche Idee ist, dass es ein Airtime Budget gibt, welches sich mit einer festen Rate auffüllt. So habe ich z. B. im Testbetrieb die Rate auf 60 Nachrichten pro Stunden begrenzt. Jede Nachrichtenart hat ihren eigenen Topf, der nach einem festen Verteilungsschlüssel einen Teil von diesem Gesamtbudget abbekommt.

Jeder Topf hat ein begrenztes Fassungsvermögen. Damit ist es möglich kurzzeitig höhere Mengen eine Nachrichtenart durchzulassen. In Zeiten mit geringem Aufkommen wird Budget angespart, welches dann in Zeiten mit höherer Auslastung aufgebraucht werden kann. Gleichbleibende Auslastung durch Bots führt so zu einer dauerhaften Drosselung. In Kanälen mit sinnvoller Diskussion kann zwischen den Diskussionen Budget angespart werden, sodass bei kurzzeitigem intensivem Austausch die Nachrichten ungehindert verbreitet werden.

Nachrichtenart Verteilungsschlüssel
GroupText ohne Region 25.00%
GroupText mit Region 25.00%
TextMessage 12.50%
Path 12.50%
Ack 12.50%
Sonstige 6.25%
Response 1.88%
Advert (Companion) 1.25%
Advert (sonstige) 1.25%
Request 1.25%
AnonRequest 0.63%

Überschüssiges Budget, welches von einer Nachrichtenart nicht benötigt wird, wird auf die anderen Arten weiterverteilt. Der Anteil nach dem Verteilungsschlüssel ist nur die durchschnittlich garantierte Menge, kann aber auch hoher sein.

Vorher-Nachher-Vergleich

Zur Validierung der neuen Firmware wurden drei Repeater am gleichen Standort mit unterschiedlicher durchschnittlicher Nachrichtenrate konfiguriert. Die Daten wurden von einem unabhängigen Observer aufgezeichnet, also nicht direkt auf den Repeatern. Die empfangenen und gesendeten Nachrichten können so nur unvollständig erfasst werden. Die Verhältnisse sind also nur eine Näherung des tatsächlichen Filterverhaltens.

Nachrichten-art Emp-fan-gen 60 Nachr./h 30 Nachr./h 10 Nachr./h
GroupText 744 622 83.6% 678 91.1% 112 15.1%
TextMessage 389 270 69.4% 300 77.1% 41 10.5%
Path 248 199 80.2% 229 92.3% 36 14.5%
Ack 52 41 78.8% 51 98.1% 33 63.5%
Response 125 42 33.6% 47 37.6% 3 2.4%
Advert (Companion) 71 49 69.0% 67 94.4% 55 77.5%
Advert (sonstige) 91 58 63.7% 67 73.6% 61 67.0%
Request 125 28 22.4% 31 24.8% 5 4.0%
AnonRequest 32 14 43.8% 14 43.8% 1 3.1%
Gesamt 1881 1326 70.5% 1487 79.1% 349 18.6%

In nachfolgendem Diagram ist die zu sehen, wie sich die Zusammensetzung des Paketaufkommens über die Zeit verändert hat.

Ab ca. 200 Nachrichten pro Stunde scheint das Netz voll ausgelastet zu sein. Aktuell wird deshalb auf den Testrepeatern die Menge auf 100 Nachrichten pro Stunden begrenzt.

Kanäle

Schaut man sich die Statistiken für die einzelnen Kanäle an, kann man festellen, dass die Nachrichten in dem relevanten #stuttgart Kanal ungehindert weitergeleitet werden, während bei den von Bots überlasteten Testkanälen am meisten eingespart wird.
Ohne Filter
Hash Name Anzahl Nachrichten Min Hops Ø Hops Max Hops
d9 #test 109 2 3.6 10
53 90 3 4.2 11
20 #chtest 49 6 8.3 11
11 Public 49 1 6.3 12
2e #prove 34 7 9.8 12
28 #ping 33 2 7.7 13
ab 29 2 3.7 14
bd #stuttgart 26 0 2.3 6
ca #qrv 20 3 6.9 11
8b 18 4 5.6 8
6b 15 5 7.5 9
e7 #switzerland 14 6 8.2 11
81 12 1 5.5 9
1d 11 3 6.3 8
06 11 5 7.6 10
df 10 2 3.5 7
0a 10 5 7.3 10
ec 9 5 8.2 10
46 9 6 9.9 17
10 8 2 4 7
62 #wetter 8 3 5.8 12
da 8 8 9 11
0d 7 6 7.9 10
5a #test-bw 7 3 3.9 5
a2 6 7 8.8 10
aa 6 1 5.8 11
c1 6 7 8.3 11
d9 5 8 12.8 19
50 #flachwitze 5 3 6.8 9
bf 5 5 6.6 10
11 5 4 11.4 16
0d #freiburg 4 5 7 9
bc 4 8 11 14
f6 4 5 7.3 10
bf #basel 4 8 9 10
a8 #xxx1 3 0 5.3 10
0c 3 6 6 6
e0 3 7 8.3 11
5e 3 6 8.3 10
eb 3 4 7 10
5a 3 2 6.7 9
06 #mctechtalk 3 2 3 4
fa 3 9 9.7 10
55 #netzstatus 3 1 3.7 7
94 3 2 2.7 3
83 Ticino 2 8 8.5 9
23 2 4 4 4
d1 2 6 6.5 7
ad 2 3 3.5 4
b3 #hamradio 2 8 9 10
ca 2 11 13.5 16
bd 2 10 10.5 11
4b 2 3 3 3
4b 2 1 3.5 6
71 #suisse 2 8 10 12
25 2 9 11 13
28 2 12 14 16
90 2 8 8.5 9
d7 1 21 21 21
d5 1 6 6 6
7c 1 9 9 9
6d 1 3 3 3
a5 1 9 9 9
ea 1 5 5 5
03 1 10 10 10
ca #bot 1 6 6 6
0f 1 3 3 3
ff #varazze 1 9 9 9
b6 1 11 11 11
06 Varazze 1 11 11 11
19 1 4 4 4
c8 1 3 3 3
95 1 3 3 3
52 1 9 9 9
58 1 7 7 7
d6 1 8 8 8
50 1 8 8 8
fb #austria 1 8 8 8
57 1 12 12 12
64 Alert-Ti 1 9 9 9
e7 1 15 15 15
4e 1 9 9 9
41 1 8 8 8
1f #saarland 1 11 11 11
3c 1 11 11 11
67 1 22 22 22
98 1 5 5 5
47 1 14 14 14
fe 1 8 8 8
37 1 9 9 9
de 1 14 14 14
45 1 13 13 13
5e Italia 1 7 7 7
64 #zuerich 1 7 7 7
bb 1 10 10 10
12 1 8 8 8
60 Nachrichten pro Stunde
Hash Name Anzahl Nachrichten Min Hops Ø Hops Max Hops
53 83 3 4.1 11
d9 #test 73 2 3 8
20 #chtest 43 6 8.3 11
11 Public 37 1 6.2 12
28 #ping 30 2 7.6 13
2e #prove 29 7 9.8 12
ab 23 2 3.1 6
bd #stuttgart 22 0 2.4 6
ca #qrv 20 3 6.9 11
8b 16 4 5.5 8
e7 #switzerland 11 6 7.8 10
6b 11 6 7.5 9
df 10 2 3.5 7
81 10 1 5.8 9
ec 9 5 8.2 10
1d 9 3 6.1 7
0a 8 5 7 10
46 8 6 9 16
da 8 8 9 11
06 8 5 7.5 9
62 #wetter 7 3 6.1 12
0d 7 6 7.9 10
10 6 2 4 7
c1 6 7 8.3 11
5a #test-bw 6 3 4 5
a2 5 7 8.8 10
aa 5 1 6.2 11
50 #flachwitze 5 3 6.8 9
bf 5 5 6.6 10
11 5 4 11.4 16
0d #freiburg 4 5 7 9
f6 4 5 7.3 10
bf #basel 4 8 9 10
a8 #xxx1 3 0 5.3 10
0c 3 6 6 6
e0 3 7 8.3 11
5e 3 6 8.3 10
fa 3 9 9.7 10
55 #netzstatus 3 1 3.7 7
23 2 4 4 4
d1 2 6 6.5 7
ad 2 3 3.5 4
bc 2 8 8.5 9
b3 #hamradio 2 8 9 10
ca 2 11 13.5 16
bd 2 10 10.5 11
4b 2 3 3 3
eb 2 7 8.5 10
06 #mctechtalk 2 2 2.5 3
4b 2 1 3.5 6
28 2 12 14 16
5a 2 2 5.5 9
90 2 8 8.5 9
94 2 2 2.5 3
83 Ticino 1 8 8 8
d5 1 6 6 6
7c 1 9 9 9
6d 1 3 3 3
a5 1 9 9 9
ea 1 5 5 5
03 1 10 10 10
ca #bot 1 6 6 6
0f 1 3 3 3
b6 1 11 11 11
06 Varazze 1 11 11 11
c8 1 3 3 3
95 1 3 3 3
52 1 9 9 9
58 1 7 7 7
d6 1 8 8 8
50 1 8 8 8
fb #austria 1 8 8 8
57 1 12 12 12
64 Alert-Ti 1 9 9 9
e7 1 15 15 15
71 #suisse 1 12 12 12
4e 1 9 9 9
d9 1 8 8 8
41 1 8 8 8
25 1 13 13 13
1f #saarland 1 11 11 11
3c 1 11 11 11
67 1 22 22 22
fe 1 8 8 8
37 1 9 9 9
de 1 14 14 14
45 1 13 13 13
5e Italia 1 7 7 7
64 #zuerich 1 7 7 7
bb 1 10 10 10
12 1 8 8 8
30 Nachrichten pro Stunde
Hash Name Anzahl Nachrichten Min Hops Ø Hops Max Hops
53 86 3 4.2 11
d9 #test 81 2 3.2 9
20 #chtest 43 6 8.1 10
11 Public 42 1 5.8 12
28 #ping 32 2 7.6 13
2e #prove 30 7 9.8 12
ab 28 2 3.4 8
bd #stuttgart 26 0 2.3 6
ca #qrv 20 3 6.9 11
8b 17 4 5.6 8
6b 15 5 7.5 9
e7 #switzerland 14 6 8.2 11
81 12 1 5.5 9
1d 11 3 6.3 8
06 11 5 7.6 10
df 10 2 3.5 7
0a 10 5 7.3 10
10 8 2 4 7
ec 8 5 8 10
46 8 6 9 16
62 #wetter 7 3 6 12
0d 7 6 7.9 10
da 7 8 8.9 11
5a #test-bw 7 3 3.9 5
a2 6 7 8.8 10
aa 6 1 5.8 11
50 #flachwitze 5 3 6.8 9
c1 5 7 7.8 8
bf 5 5 6.6 10
11 5 4 11.4 16
0d #freiburg 4 5 7 9
f6 4 5 7.3 10
a8 #xxx1 3 0 5.3 10
0c 3 6 6 6
e0 3 7 8.3 11
5e 3 6 8.3 10
eb 3 4 7 10
5a 3 2 6.7 9
06 #mctechtalk 3 2 3 4
bf #basel 3 8 8.7 9
fa 3 9 9.7 10
55 #netzstatus 3 1 3.7 7
d9 3 8 12 16
94 3 2 2.7 3
83 Ticino 2 8 8.5 9
23 2 4 4 4
d1 2 6 6.5 7
ad 2 3 3.5 4
bc 2 8 8.5 9
b3 #hamradio 2 8 9 10
ca 2 11 13.5 16
bd 2 10 10.5 11
4b 2 3 3 3
4b 2 1 3.5 6
71 #suisse 2 8 10 12
25 2 9 11 13
28 2 12 14 16
90 2 8 8.5 9
d5 1 6 6 6
7c 1 9 9 9
6d 1 3 3 3
a5 1 9 9 9
ea 1 5 5 5
03 1 10 10 10
ca #bot 1 6 6 6
0f 1 3 3 3
ff #varazze 1 9 9 9
b6 1 11 11 11
06 Varazze 1 11 11 11
19 1 4 4 4
c8 1 3 3 3
95 1 3 3 3
52 1 9 9 9
58 1 7 7 7
d6 1 8 8 8
50 1 8 8 8
fb #austria 1 8 8 8
57 1 12 12 12
64 Alert-Ti 1 9 9 9
e7 1 15 15 15
4e 1 9 9 9
41 1 8 8 8
1f #saarland 1 11 11 11
3c 1 11 11 11
67 1 22 22 22
98 1 5 5 5
47 1 14 14 14
fe 1 8 8 8
37 1 9 9 9
5e Italia 1 7 7 7
64 #zuerich 1 7 7 7
12 1 8 8 8
10 Nachrichten pro Stunde
Hash Name Anzahl Nachrichten Min Hops Ø Hops Max Hops
bd #stuttgart 21 0 2 4
53 19 3 3.4 5
ab 16 2 2.8 6
11 Public 9 1 2.3 4
df 7 2 2.6 3
8b 4 4 5 7
aa 3 1 3 4
81 3 2 2.7 3
62 #wetter 3 3 3 3
28 #ping 3 2 3 4
5a #test-bw 3 3 4.3 5
4b 2 3 3 3
06 #mctechtalk 2 2 2.5 3
55 #netzstatus 2 1 2 3
ca #qrv 2 3 3 3
94 2 3 3 3
a8 #xxx1 1 0 0 0
ad 1 3 3 3
19 1 4 4 4
c8 1 3 3 3
95 1 3 3 3
eb 1 4 4 4
50 #flachwitze 1 3 3 3
4b 1 6 6 6
5a 1 2 2 2
d9 #test 1 2 2 2
10 1 3 3 3

Download

Binaries: https://mesh.q60.de/qos/repeater-firmware/

Quellcode: https://github.com/slisson/MeshCore/tree/qos

Konfiguration

Mit dem CLI Befehl
set qos.rate 100
kann die durchschnittliche Anzahl an weitergeleiteten Nachrichten verändert und mit
get qos.rate
entsprechend ausgelesen werden. Standardmäßig liegt der Wert bei 60 Nachrichten pro Stunde. Ohne Filterung werden Werte von maximal ca. 200 Nachrichten pro Stunde erreicht. Mit einem höheren Wert wäre der Filter effektiv deaktiviert. Die Einstellung sollte also deutlich darunter liegen.

Initiales Verhalten

Nach dem Start des Repeaters sind die meisten Budgettöpfe vollständig gefüllt. Dadurch werden die zu Begin die meisten Nachrichten ungefiltert durchgeleitet. Es dauert einige Stunden bis der Filter sich vollständig an den lokalen Netzwerkverkehr angepasst hat.