Jungs? Alles ganz spannend, aber wollt ihr vielleicht die 4 Messungen auf Euren jeweiligen Links durchfuehren und die Resultate hier teilen? Firma dankt!
Bitte um Messhilfe
-
ich weiß immer noch nicht auf was du hinaus willst?
-
ich weiß immer noch nicht auf was du hinaus willst?
Das glaube ich sofort. Aber brems du mal weiter schön das Licht ab.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Jungs? Alles ganz spannend, aber wollt ihr vielleicht die 4 Messungen auf Euren jeweiligen Links durchfuehren und die Resultate hier teilen? Firma dankt!
Ich verstehe deinen Ansatz nicht. Übertragungen mit kleinen Datenpaketen werden kaum die Leitung auslasten können.
Zudem müsste ich dafür SQM vorher deaktivieren. Mache ich dann mal morgen, auch wenn ich deinen Ansatz nicht verstehe.
-
ich weiß immer noch nicht auf was du hinaus willst?
Nun, der Thread geht um meine Bitte 4 iperf3 Messungen durchzufuehren und die Resultate hier zu teilen? D.h. auf was ich hinaus will sind Messdaten...
-
Ich verstehe deinen Ansatz nicht. Übertragungen mit kleinen Datenpaketen werden kaum die Leitung auslasten können.
Warum sollten die das nicht koennen? Ich habe die Messungen auf meinem Link bereits durchgefuehrt, und konnte meinen DSL100 Link sowohl mit MSS 1452 als auch mit MSS 216 Paketen saettigen. Klar, dazu muessen Router und Endgeraete potent genug sein um mit der hoeheren Paket-Last klar zu kommen, und es kommt weniger Goodput dabei raus, aber genau das will ich analysieren, wie shapen ISPs.
Zudem müsste ich dafür SQM vorher deaktivieren.
Ja, gute Bemerkung, hatte ich vergessen zu erwaehnen, da es mir um den ISP-seitigen Shaper geht sind lokale Shaper dabei zu deaktivieren.
Mache ich dann mal morgen, auch wenn ich deinen Ansatz nicht verstehe.
Super, besten Dank. Ich werde das morgen versuchen noch mal etwas ausfuehrlicher zu erklaeren.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Im Gegensatz zu den anderen finde ich das einen interessanten Ansatz und bin auf das Ergebnis gespannt. Leider gibt der Markt oder die BNetzA hier keine wirklichen Vorgaben raus, auf welchem Layer die Shaper zu funktionieren haben. Es heißt immer nur, dass auf Applikationsebene die Bandbreite erreicht werden soll. Paketgrößen werden hier aber nicht genannt.
Je nachdem welche Hersteller so eingesetzt werden, kann man das Shaping Overhead sehr individuell setzen: https://supportportal.juniper.net/s/article/MX-C…overhead-in-CoS
-
Messhilfe - NDiGF, Test 1v4 (small, reverse).txt
Messhilfe - NDiGF, Test 2v4 (small).txt
Messhilfe - NDiGF, Test 3v4 (normal, reverse).txt
Messhilfe - NDiGF, Test 4v4 (normal).txtISP: Telekom, FTTH (GPON)
Tarif: 600Mb/s DS, 300Mb/s US
Router: FRITZ!Box 5590 (Ver. 8.40), Shapping im US aktiv bei 310Mb/sTest-Client 1: Arch-Linux (*:2280)
Test-Client 2: Debian 13 (*:262f)Hinweis:
Anschluss befand sich zum Testzeitpunkt leider nicht im Leerlauf (Mehrpersonenhaushalt, u.a. TV/Streaming von anderen Clients aktiv)! -
Ergänzung: Mit UDP wäre es vermutlich einfacher korrekte Werte zu erhalten, ab wann der Shaper zu droppen anfängt. TCP hat wegen Congestion Control teilweise erhelibe Schwankungen und beeinflusst somit die Messung.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
So richtig glücklich war ich mit meinen Testergebnissen nicht, hatte eher den Eindruck nicht den BNG-Shapper zu testen sondern eher meinen Router. Die CPU-Last ging (bei kleiner Paketgröße) auch recht hoch.
Habe daher den Test wiederholt und dabei die sog. "Upstream-Optimierung" deaktiviert (bedeutet imo nicht, das damit der US-Shaper deaktiviert wird) als auch die sog. Bandbreiten-Reservierung. Diese Optionen scheinen das Offloding weniger effizient zu machen. Zumindest der Test 1v4 sieht nun deutlich besser aus (diesmal nur mit dem Debian 13 System getestet):
Messhilfe - NDiGF, Test 1v4 #2 (small, reverse).txt
Messhilfe - NDiGF, Test 2v4 #2 (small).txt
Messhilfe - NDiGF, Test 3v4 #2 (normal, reverse).txt
Messhilfe - NDiGF, Test 4v4 #2 (normal).txt -
Ich habe die vier Messungen auf zwei Rechnern durchgeführt.
Anschluss: E.ON Highspeed 1000 (1000/500 Mbit/s), GPON, IPoE per DHCP (kein PPPoE, MTU 1500). Gemessen wurde über IPv6, die MSS 1452 wird damit effektiv auf 1440 begrenzt. Router ist eine FRITZ!Box 5590 Fiber ohne SQM und ohne Priorisierung. Im Alltag erreiche ich ca. 930 Mbit/s im Download und ca. 570 Mbit/s im Upload.
Test-PC #1: Intel i3-N305, 48 GB RAM, Windows 11 Pro, Intel 82599 10G, iperf3 3.21 (Cygwin-Build), TCP-Timestamps vermutlich nicht genutzt
Test-PC #2: Intel i5-10400, 128 GB RAM, Unraid 7.3.2 (Kernel 6.18), Mellanox ConnectX-3 10G über Bridge, iperf3 3.21, TCP-Timestamps an, Staukontrolle BBR
Beide Rechner hängen per 10G im LAN.Ergebnisse in Mbit/s (Receiver über 20 s, in Klammern grob die stabile Phase):
Messung Test-PC #1 (Windows) Test-PC #2 (Linux) Download MSS 216 665 (ca. 685) 459 (ca. 470) Download MSS 1452 902 (ca. 925) 910 (ca. 930) Upload MSS 216 nicht verwertbar (siehe unten) 336 (ca. 365) Upload MSS 1452 519 (ca. 570) 528 (ca. 570 bis 600) Zum Upload von Test-PC #1: Der Cygwin-Build von iperf3 ignoriert -M beim Senden offenbar, Windows kennt die Socket-Option TCP_MAXSEG so nicht. Lokal von Test-PC #1 zu Test-PC #2 kamen mit -M 216 nämlich 8,73 Gbit/s an, mehr als die ca. 7,35 Gbit/s, die mit MSS 216 auf 10GbE überhaupt möglich wären. Mit -M 1452 waren es exakt die rechnerischen 9,49 Gbit/s. Der Upload mit MSS 216 lief also in Wirklichkeit mit großen Paketen. Im Download betrifft das nicht, da setzt der Server die MSS.
Gegenprobe im LAN: Von Test-PC #2 zu Test-PC #1 kommen mit MSS 216 rund 4 Gbit/s an. Test-PC #1 kann kleine Pakete also deutlich schneller verarbeiten, als der Anschluss liefert, und sollte beim Download nicht limitieren. Die FRITZ!Box selbst ist damit allerdings nicht geprüft, weil der LAN-Verkehr nicht durch ihr Routing läuft. Die niedrigeren Download-Werte von Test-PC #2 mit MSS 216 gehen vermutlich auf den Rechner selbst zurück, der über eine Bridge mit Docker und VMs empfängt.
Die Priorisierung von Test-PC #1 in der FRITZ!Box hatte übrigens keinen messbaren Einfluss. Mit und ohne lagen die Werte praktisch gleich.
Auffällig ist noch: Im Upload mit MSS 216 hängen die einzelnen Streams auf Test-PC #2 fast immer bei ca. 45, 90 oder 135 Mbit/s, obwohl die Cwnd mit 1 bis 2 MB groß genug ist. Ob das mit BBR zusammenhängt, kann ich nicht beurteilen.
Die vollständigen Logs kann ich bei Bedarf nachreichen.
-
Eine Ergänzung zu meinen Messungen in #31.
Angeregt durch die Beobachtung von NDiGF in #30 habe ich in der FRITZ!Box nachgesehen. Unter Internet → Zugangsdaten → Verbindungseinstellungen war als Upstream 650 Mbit/s eingetragen. Das liegt zwar über dem, was der Anschluss im Upload tatsächlich durchlässt (ca. 570 bis 600 Mbit/s), die FRITZ!Box nutzt diesen Wert aber für ihre eigene Priorisierung und verwaltet den Upload damit selbst. Die Bandbreitenreservierung für das Heimnetz ist bei mir deaktiviert.
Ich habe den Upstream testweise auf 1000 gesetzt und den Upload mit MSS 216 auf Test-PC #2 wiederholt:
Upstream 650: 336 Mbit/s (stabile Phase ca. 365)
Upstream 1000: 375 Mbit/s (stabile Phase ca. 410)Das sind etwa 10 % mehr, bei einer Einzelmessung aber noch im Bereich der normalen Schwankung. Die auffälligen Stufen von ca. 45, 90 und 135 Mbit/s je Stream sind geblieben, die kommen also offenbar nicht von dieser Einstellung.
Noch ein Detail, das für die Rechnung wichtig sein dürfte: Mein Zugang läuft über VLAN 132 (getaggt), pro Paket kommen also noch 4 Byte dazu.
Wenn ich Zeit finde, wiederhole ich die Messungen jeweils mehrfach, damit die Werte belastbarer werden.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Bei einer MSS von 216 Bytes und 300 Mbit/s landen wir schon bei 170.000 pps. Ich könnte mir vorstellen, dass das die Fritz und auch andere kleine Router an ihre Grenzen bringt.
-
Einerseits ja. Andererseits soll ja die 5590 auch mehr als 2,5Gb/s NAT- bzw. gar PPPoE-Durchsatz schaffen, bzw. eben (in Richtung Heimnetz) nur durch den NBase-T-Port begrenzt. Da liegt man dann auch bei mehr als 200.000pps mit 1.452Bytes.
-
NDiGF und Thomas1978 vielen lieben Dank! Ihr habt direkt ein paar Fallstricke in meiner Mrethodik entdeckt und offen gelegt, dafuer Dank:
- lokales Traffic-Shaping:
um dem BNG Shaper auf den Pelz ruecken zu koennen, muss der lokale Shaper umgangen werden, am elegantesten wenn man ihn einfach abschaltet, alternativ in dem man den Wert sehr hoch setzt (aber in der Vergangenheit gab es Geruechte, dass Fritzboxen im 2. Fall schlicht die Kundeninformation ignoriert haben , zumindest wenn der ISP Shapinginformation en im PPPoE-AuthACK gesendet hatte) - IP-Version:
Ich bin bei den iperf3-Befehlen naiv davon ausgegangen, dass der Test ueber IPv4 laufen wuerde (bei meinen ersten Tests mit den Befehlen lief das bei mir ueber IPv4, und mir ist nicht aufgefallen, dass die spaeteren Tests IPv6 verwendeten). Daher ist die MSS nur bedingt sinnvoll. - Kontrolle der effektiven MSS, und etwaiger TCP Optionen:
Einstellen kann man viel, aber nicht alle Einstellungen werden von Betriebssystemen auch umgesetzt... Unter:
https://browserleaks.com/tcp
Kann man sich im Browser zeigen lassen, welche MSSD ausgehandelt wurde, und ob TCP Timestamps aktiv waren, beides relevante Information fuer die Auswertung - Kontrolle der Paketgroesse Teil 2:
Ein Browsertest ist interessant sagt aber erst mal nur was ausgehandelt wurde, nicht zwingend was tatsaechlich umgesetzt wurde, ich habe daher zusaetzlich noch Packet-Captures waerend des iper3 Tests gemacht (schnell und schmutzig mit wireshark) und darauf geachtet ob ich waehrend der Lastphasen Paketgroessen in der erwartbaren Grioessenordnung sehe (ich habe bei IPv4 270 Bytes gesehen (290 bei IPv6), 216+12+20+20 = 268, dazu kommt bei der Wirehark Anzeige noch 2 Byte ethertype, also in der Summe 270, passt also).
Als Konsequenz aus diesen Informationen aendere ich die Bitte etwas um:
Codeiperf3 -M 216 -c ren.bbr.iperf.bytel.fr -T MSS216_download -p 9210 --parallel 4 -t 20s --reverse -6 iperf3 -M 216 -c ren.bbr.iperf.bytel.fr -T MSS216_upload -p 9210 --parallel 4 -t 20s -6 iperf3 -M 1432 -c ren.bbr.iperf.bytel.fr -T MSS1432_download -p 9210 --parallel 4 -t 20s --reverse -6 iperf3 -M 1432 -c ren.bbr.iperf.bytel.fr -T MSS1432_upload -p 9210 --parallel 4 -t 20s -6Zusaetzlich bitte ich um Information zu den Vertragsraten, dem ISP (weniger wichtig, aber neugierig nin ich schon
), und der Verkapselung so weit bekannt (PPPoE oder IPoE/DHCP, VLAN(s), ...), das ist natuerlich alles freiwillig. UNd wie oben angemerkt Information zur MSS und ob TCP Timestamps aktiv waren.Sollte das nicht funktionieren, weil der Link kein natives IPv6 erlaubt, dann wuerde ich die Daten erstmal ausklammern, weil CG-NAT/ds-lite zusaetzliche Herausforderungen sind die ich erstmal ignorieren will.
Nochmal, vielen lieben Dank!P.S.: Mehrfachmessungen sind grossartig! Fuer meinen Zweck ist dann das Maximum ueber alle Messungen der beste Schaetzer (nicht jedoch das Maximum ueber die 1 Sekunden Reports waehrend eines Tests, die leiden alle unter dem Retransmissions-Problem).
- lokales Traffic-Shaping:
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Hier mal die Messungen eines DG 400/200 Anschlusses AON. Hinweis: In Senderichtung greift der Trafficshaper meiner Fritzbox 5530.
-
Mit UDP wäre es vermutlich einfacher korrekte Werte zu erhalten
Guter Punkt, muss ich noch ausprobieren, waere auf jeden Fall "rauher" fuer den Resttraffic auf dem Link.
Bei einer MSS von 216 Bytes und 300 Mbit/s landen wir schon bei 170.000 pps. Ich könnte mir vorstellen, dass das die Fritz und auch andere kleine Router an ihre Grenzen bringt.
Ja, das ist in der Tat eine der Herausforderungen hierbei.
-
Hier die neue Runde mit den Befehlen aus #35, jeweils dreimal hintereinander mit 15 Sekunden Pause dazwischen.
Anschluss: E.ON Highspeed 1000 (1000/500 Mbit/s), GPON im Netz von Westconnect, IPoE per DHCP (kein PPPoE), VLAN 132 getaggt, natives IPv6.
Router: FRITZ!Box 5590 Fiber, Upstream in den Verbindungseinstellungen auf 1000 Mbit/s gesetzt (vorher 650), damit der lokale Shaper nicht greift. Bandbreitenreservierung und Priorisierung aus.
Gemessen nur mit Test-PC #2 (Unraid 7.3.2, Kernel 6.18, Staukontrolle BBR), weil der Windows-PC -M beim Senden ignoriert. TCP-Timestamps sind laut sysctl aktiv, die MSS habe ich nicht per Mitschnitt geprüft.Ergebnisse in Mbit/s (Receiver-Werte):
Messung Lauf 1 Lauf 2 Lauf 3 Maximum MSS216_download 548 475 571 571 MSS216_upload 247 388 356 388 MSS1432_download 914 910 908 914 MSS1432_upload 508 525 513 525 Die Werte mit großen Paketen sind sehr stabil, die mit kleinen Paketen schwanken deutlich.
Ein Hinweis zum Download mit MSS 216: Test-PC #1 (Windows) kam in #31 bei MSS 216 auf ca. 685 Mbit/s, also deutlich mehr als der Unraid-Server. Der Download ist davon nicht betroffen, dass Windows -M beim Senden ignoriert, weil dort der Server die MSS setzt. Ich vermute daher, dass Unraid bei kleinen Paketen im Empfang selbst limitiert. Für den Download mit MSS 216 halte ich den Wert vom Windows-PC für aussagekräftiger.
Die vollständigen Logs kann ich bei Bedarf nachreichen.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Vielen Dank. Ich fuerchte ob der hohen Paketrate bei MSS und hohen Kapazitaeten, macht es Sinn nach Anschluessen mit 50, 100oder 150 Mbps zu suchen, da ist es leichter den Link mit kleinen Paketen zu saettigen ohne, dass das Router-SoC einen Herzinfarkt bekommt
-
(aber in der Vergangenheit gab es Geruechte, dass Fritzboxen im 2. Fall schlicht die Kundeninformation ignoriert haben , zumindest wenn der ISP Shapinginformation en im PPPoE-AuthACK gesendet hatte)
Exakt das ist das Problem, man kann ihn in diesem Fall nicht wirklich deaktivieren.
Wenn dann würde ich eher meinen OpenWRT-Router (MediaTek Filogic 820 basiert) temporär anschließen zum messen. Aber bei einem Tripple-Play Anschluss in einem Mehrpersonenhaushalt sind solche "Spielereien" halt nicht so einfach durchführbar.
