da in der WA Gruppe nach Meinungen gefragt wurde, wiederhole ich gerne nochmal meine Kritik an Multibyte, die ich bereits in der Telegram Gruppe geäußert habe - speziell hinsichtlich Netzauslastung.
Die neuen 2- und 3-Byte Modes machen in meinen Augen technisch überhaupt keinen Sinn:
Bei Flooding (wo jeder Repeater sowieso alles repeatet!) blasen sie nur die Pfade unnötig auf (jeder Hop bekommt nun ein oder sogar zwei Bytes mehr!)
Bei DMs helfen sie nur an Stellen, wo es Kollisionen gibt, d.h. zwei Repeater in maximal 1 Hop Entfernung die gleiche 1-Byte ID haben. Da DMs aber einerseits nur sehr wenig Traffic verursachen (10-20%?) und andererseits ID-Kollisionen in direkter Umgebung nicht übermäßig häufig auftreten, spielt das so gut wie keine Rolle. Selbst wenn es eine Kollision gibt, führt das nur lokal zu höherer Netzlast, aber es wird nichts blockiert oder kann deshalb nicht zugestellt werden.
Der einzige Vorteil ist, dass man damit Repeater als User besser identifizieren kann. Das wäre mir der zusätzliche Overhead aber definitiv nicht wert, denn ich nutze das Netz hauptsächlich zur Kommunikation, und nicht um mir ständig Pfade anzusehen. Zum Debuggen kann ich ja jederzeit Traces mit mehreren Bytes machen oder einzelne Nachrichten mit Multibyte versenden, da spricht ja nichts dagegen.
Deshalb rate ich von der generellen Verwendung von Multibyte ab.
Es macht IMHO viel mehr Sinn, bei eigenen Repeatern zu prüfen, ob schon ein anderer Repeater mit gleicher ID in der Nähe ist (maximal mit einem Hop, d.h. ein anderen Repeater dazwischen) und dann die ID zu ändern.
Das mit einer Verdoppelung der Bytes pro Hop die Paketgrösse zunimmt ist nicht wegzureden, ich sehe dies jedoch weniger dramatisch und gemäss meinen Daten würde Anzahl Bytes von 1 auf 2 Byte das Verkehrsvolumen um 16 % erhöhen. Und dies auch nur wenn alle umstellen würden, was kaum stattfinden wird. 3 Bytes halte ich übrigens auch nicht für nötig. Damit erhöht sich die Sichtbarkeit nicht weiter.
Eine Verdoppelung der Anzahl Bytes pro Hop hört sich erstmal drastisch an, aber ein Paket besteht ja nicht nur aus dem Pfad. Im Durchschnitt sehe ich 9 Hops pro Message und eine durchschnittlich Grösse von 54 Bytes.
Für mich wäre das zusätzliche Volumen vertretbar da dadurch die Sichtbarkeit auf das Netz wesentlich erhöht würde.
die meisten Bots antworten mit dem Pfad als Text, könnte man komplett weglassen, ein ACK als Antwort würde genügen, den genauen Pfad der Antwort sieht man mit “View Message Pfad”.
separates Tracen entfällt
Aus den Daten kann man eine Graphen bauen und sieht darin auch welche Repeater welche Regionen unterstützen. sieht man bei Trace nicht.
Bei Adverts und auch bei vielen Group Text Messages bestimmter Kanäle bestünde grosses Sparpotential.
Gruss
Stef
Ergebnisse — 2026-04-20 21:10
Analysezeitraum: letzte 10 Tage, gemessen am Observer zrh-trace
1. Verkehrsverteilung nach Typ
Typ
Pakete
% Pakete
Volumen
% Volumen
Ø Grösse
Δ Vol (2-Byte)
Overhead 2B%
Response
67,775
22.9%
2379.0 KB
15.2%
35.9 B
+629.5 KB
+26.5%
TextMessage
57,502
19.4%
2643.3 KB
16.8%
47.1 B
+467.7 KB
+17.7%
Request
49,800
16.8%
1647.7 KB
10.5%
33.9 B
+533.4 KB
+32.4%
GroupText
39,835
13.4%
2922.6 KB
18.6%
75.1 B
+289.1 KB
+9.9%
Advert
28,011
9.5%
3575.4 KB
22.8%
130.7 B
+130.1 KB
+3.6%
Path
27,089
9.1%
1089.4 KB
6.9%
41.2 B
+240.4 KB
+22.1%
AnonRequest
20,177
6.8%
1290.8 KB
8.2%
65.5 B
+163.6 KB
+12.7%
Ack
5,263
1.8%
123.6 KB
0.8%
24.0 B
+58.0 KB
+47.0%
Control
411
0.1%
14.8 KB
0.1%
37.0 B
-0.0 KB
±0.2%
Trace
228
0.1%
3.9 KB
0.0%
17.5 B
+0.4 KB
+9.7%
GroupData
137
0.0%
9.7 KB
0.1%
72.9 B
+2.3 KB
+23.2%
Multipart
20
0.0%
0.2 KB
0.0%
9.9 B
+0.1 KB
+29.3%
Gesamt
296,248
100%
15700.4 KB
100%
-–
+2514.5 KB
+16.0%
2. Verkehrsvolumen nach Kanal
Kanalname
Hash
Pakete
% Pakete
Volumen
% Volumen
Ø Grösse
Δ Vol (2-Byte)
Overhead 2B %
#test
D9
8,567
36.0%
719.3 KB
38.4%
86.0 B
+60.6 KB
+8.4%
public
11
4,612
19.4%
322.8 KB
17.2%
71.7 B
+29.4 KB
+9.1%
#ping
28
2,652
11.1%
197.6 KB
10.5%
76.3 B
+17.1 KB
+8.7%
?
C4
2,476
10.4%
229.2 KB
12.2%
94.8 B
+25.4 KB
+11.1%
#wardriving
81
1,159
4.9%
77.4 KB
4.1%
68.4 B
+5.9 KB
+7.6%
?
E0
1,051
4.4%
63.4 KB
3.4%
61.8 B
+7.0 KB
+11.0%
#switzerland
E7
932
3.9%
83.5 KB
4.5%
91.7 B
+4.4 KB
+5.3%
italia
5E
929
3.9%
71.3 KB
3.8%
78.6 B
+5.8 KB
+8.2%
#chtest
20
750
3.2%
55.9 KB
3.0%
76.3 B
+3.6 KB
+6.4%
#suisse-romande
AA
665
2.8%
54.7 KB
2.9%
84.2 B
+2.8 KB
+5.1%
3. Pfadlängenverteilung
Pfadlänge (Hops)
Pakete
%
1
3,389
1.2%
2
9,537
3.3%
3
18,558
6.3%
4
25,825
8.8%
5
28,470
9.7%
6
27,516
9.4%
7
24,879
8.5%
8
22,493
7.7%
9
18,784
6.4%
10
15,825
5.4%
11
13,925
4.7%
12
12,213
4.2%
13
10,661
3.6%
14
9,952
3.4%
15
9,449
3.2%
16
8,717
3.0%
17
6,968
2.4%
18
5,962
2.0%
19
4,855
1.7%
20
3,866
1.3%
21
2,704
0.9%
22
1,975
0.7%
Gesamt
293,307
100%
Zeilen mit < 0,5 % ausgeblendet (7k Pakete).
Durchschnittliche Pfadlänge: 9.25 Hops
4. Volumenauswirkung: Wechsel von 1-Byte/Hop auf 2-Byte/Hop (gesamt)
Aktuelle path_hash_size-Verteilung (Pakete mit Pfaddaten und bekannter Länge):
1 Byte/Hop: 276,639 Pkt (94.3%)
2 Byte/Hop: 15,503 Pkt (5.3%)
3 Byte/Hop: 1,151 Pkt (0.4%)
Kennzahl
Aktuell
Mit 2-Byte/Hop
Analysierte Pakete
293,305
-–
Gesamtvolumen
15546.7 KB
18060.9 KB
Ø Paketgrösse
54.3 B
63.1 B
Pfadfeld-Bytes gesamt
2786.2 KB
5300.4 KB
Pfad-Mehrvolumen
-–
+2514.2 KB (+16.17% des Gesamtvolumens)
Fazit: Durch den Wechsel jedes Hop-Encodings auf 2 Bytes würde 2514.2 KB Mehrvolumen entstehen (16.17% des Gesamtverkehrs), da das Pfadfeld für Pakete mit 1-Byte-Hops verdoppelt wird. Der Vorteil ist eine deutlich geringere ID-Kollisionsrate und damit zuverlässigere Pfadauflösung und Sichtbarkeit
Vielen Dank für die präzise Erklärung zu diesem interessanten Thema. Auch wenn eine Erhöhung des Traffics nicht wirklich wünschenswert ist, so hat der Wechsel auf z.B. 2 Bytes aus meiner Sicht durchaus einen Mehrwert. Wenn dafür ein paar Bots abgeschaltet werden, so haben wir den Traffic schnell wieder auf dem ursprünglichen Level oder darunter
Südlich der Alpen und in Italien haben wir am 28-4-2026 mit der Umstellung auf 2 byte begonnen. Die wichtigsten Repeater sind zum jetzigen Zeitpunkt schon auf path.hash.mode 1 (2 Byte) umgestellt. Regions werden genutzt und sind mitlerweile akzeptiert worden.
