Also wenn ich jetzt so gucke, ist die TQ für den Offloader auf 100% muss man mal beobachten ob das schwankt.
Zur Load auf den Gateways: Die ist so ziemlich in Ordnung. Das hängt damit zusammen, dass die Systeme mehr als ein Kern haben und somit auch bei einer Last von 1 noch ohne Probleme laufen und keinen Ärger machen.
Das ist eher auszuschließen, da das Mesh Protokoll und auch sonst niemand solchen Dinge tut. Einzig wenn der Traffic Shaper auf dem Offloader aktiv wäre, könnte so etwas passieren. Aber der ist deaktiviert. Ansonsten fast da nix den Traffic an. Aber eine interessante Beobachtung.
So, wie versprochen hier mal noch die Befehle zum Testen. Bitte unbedingt nicht auf dem Knoten oder Offloader ausführen, sondern auf einem Gerät das per Kabel an einem Mesh on LAN Knoten hängt.
Ich habe gestern nach den Tests noch einen Versuch unter reellen Bedingungen gemacht. In der ganzen Unterkunft gibt es nicht einen, der per Kabel an einem Router hängt. Deshalb habe ich über WLAN ein Linux update gemacht (ca.300MB Daten mit Dateien in unterschiedlicher Größe) Die Downloadrate schwankte dabei zwischen 0,4 - 2 Mbit/s. Die Grafana Statistik zeigte keine deutlichen Veränderungen, wie ich sie z.B. durch die iperf Messungen erzeugen konnte.
Auch die gemessenen Werte machen mich etwas stutzig. Mit 20 parallelen Verbindungen zu deinem Server über IPv4 knapp 80Mbit/s über IP6 nur 25Mbit/s. Irgendwo ist doch da bei v6 der Wurm drin…
Bis zum Gateway scheint die Strecke über v6 gut zu sein was die erste, dritte und letze Messung zeigt. Das Problem müsste dann nach meinem Verständnis also die Strecke vom Eingangs- zum Ausgangsgateway sein.
Ich glaube eher wir müssen hier zwischen der IPv6 Performance und dem eigentlichen Problem unterscheiden, denn beide Anbindungen würden ja genug her geben, um eine schnelle Verbindung zu ermöglichen. Auch, dass das Problem jetzt hier so spezifisch auftaucht, während ich an einem anderen Offloader am gleichen Gateway meine 70-80Mbit/s bekomme ist komisch. Inbesondere auch das du mit den parallelen Verbindungen eine höhere Bandbreite erreichst ist interessant und sollte im Normalfall, wenn die erreichbare Bandbreite ein Problem ist nicht so entstehen.
Ich bleibe dabei, dass ich hier ein TCP Problem vermute. Könntest du daher mal bitte auf einem Rechner das Tool MTR installieren und sowohl gegen deinen Gateway als auch gegen die 8.8.8.8 und 2001:4860:4860::888 einen mindestens 5 Minuten dauernden Test fahren, damit wir sehen ob es über die Leitung zu Paketverlusten kommt. Hier bitte explizit über das WLAN wenn der Empfang gut ist.
MTR hat da noch einen Report-Mode. Diesen mit dem Argument -r aktivieren und die Zeit mit -c [Pings] angeben. Die Befehlszeile wäre dann mtr -r -c 300 [IP]. Die Ausgabe sollte dann auch geeignet sein, um diese irgendwohin zu pasten.
Was ich daraus lesen kann, ist an welcher Stelle wie viele Pakete verloren gehen. Wie schon weiter oben gesagt, ist TCP was Paketverlust angeht sehr sehr pingelig. Die Zahlen kann ich jetzt in eine Formel reinpacken und dir die maximale Geschwindigkeit berechnen.
Das bedeute, wenn man von diesem Paketverlust als dauerhaften Wert ausgeht, sind folgende maximale Geschwindigkeiten via TCP möglich.
Für den Weg zum Gateway bei 5.3% Loss sind das maximal noch:
Da du auch schon höhere Werte gemessen hast und sich durch die Parallelmessungen gezeigt hat, das es hilft mehrere TCP Verbindung zu nutzen, vermute ich das hier Paketverluste unser Problem sind. Ich werfe jetzt auch nochmal entsprechende Tests auf dem Offloader an.