Wie effektive (Netto-) Wlan-Geschwindgkeit ermitteln?

[spcqike]

Du hast es bereits abgelehnt, aber ich sage es einfach nochmal Wenn einem die Verbindung wichtig ist und man den Durchsatz erreichen will, geht nichts über ein Kabel. Vor allem, wenn nur 5m und 2 Rigipswände dazwischen sind. Da hätte ich gar nicht erst darüber nachgedacht, >100€ in 2 Repeater zu investieren.

WLAN ist und bleibt ein geteiltes Medium. Wenn es heute gut läuft, kann es morgen bei schlecht Wetter und aktiver Mikrowelle und dem Nachbarn, der Updates lädt, wieder ganz anders aussehen.

Aber ich gebe dir recht, bei den Geräten erscheint mir eine ~200Mbit Netto Verbindung auch arg wenig.

 

[foo_1337]

5ghz hasst Wände, auch Rigips Wände. Und wenn da direkt 2 dazwischen sind, kann es schon schnell passieren, dass nur noch 200Mbit/s drin sind.

 

[nukin]

Nein kann in dem Fall nicht sein. Ich denke es liegt nicht am WLAN, sondern an der Messung oder der FB. Ich habe den AP testweise in einem weiter entfernten Raum mit einer weiteren Wand dazwischen gemessen. Laut AP kommen hier brutto nur noch knapp 1.800 Mbit an. Laut iperf 15 Mbit netto weniger. Versuche mich mal durch die iperf Kommandozeilen zu kämpfen. Ansonsten muss ich im Zweifel einfach noch mal messen, wenn die Glasfaser auch anliegt.

 

[foo_1337]

Dh du hast noch nicht auf UDP umgestellt? Das ist einfach via -u und port 4712 machbar. Wenn du bei TCP bleibst, ist die CPU der FB das Bottleneck.
Also z.B. iperf -c x.x.x.x -p 4712 -u -t 60 -i 10 -b 1000M

 

[Samurai76]

Und ja, je nach FB Modell limitiert die CPU schon bei 100MBit/s im TCP Test. Mit UDP konnte ich dagegen auch 1GBit/s ausmessen (per Kabel, da kamen dann ~980MBit/s raus}.

 

[foo_1337]

@Samurai76 ich ging fälschlicherweise davon aus, dass er das nach deinem Hinweis schon gemacht hatte

 

[riversource]

Ich halte gar nichts davon, gegen die Fritzbox zu messen. Dabei ist bei mir nie ein brauchbares Ergebnis herausgekommen. Fritzboxen sind gut darin, Pakete weiterzuleiten, dafür haben sie auch eine Paketbeschleunigung. Aber sie selber zu senden oder zu empfangen ist nicht ihre Stärke. Das verfälscht die Ergebnisse massiv, auch bei UDP. Außerdem halte ich iperf3 für das bessere Werkzeug.

Darüber hinaus sollte man mit mehreren parallelen Streams testen, nicht nur mit einem:

iperf -c x.x.x.x -P 10 (-u -b 100M) (-R)

Die Parameter in Klammern kann man optional verwenden, wenn man UDP oder die Gegenrichtung testen will.

Also: Ein Server, am besten auf einem am LAN angeschlossenen Gerät, und dann per WLAN testen.

 

[foo_1337]

Schön, dass du deine Erfahrungen mit anderen Konstellationen teilst. Der TE hat jedoch keine andere Möglichkeit und für das geplante Gigbit, was er erhalten wird, reicht die UDP Variante eben. Und nein, mehrere parallele Streams sind hier Kontraproduktiv

 

[riversource]

Der TE hat jedoch keine andere Möglichkeit

Dann ist es zwecklos. Nur um des Messens willen zu messen ergibt keinen Sinn. Die Ergebnisse sind jedenfalls nicht aussagekräftig.
Frei nach dem Motto:

"Warum misst du?"
"Weil ich es kann."

Und nein, mehrere parallele Streams sind hier Kontraproduktiv

Sind sie nie, das liegt einfach in den grundsätzlichen IP-Mechanismen begründet. Es ist auch praxisnäher. Wenn bei mehreren parallelen Streams ein schlechteres Ergebnis rauskommt, als bei einem Stream, dann weiß man direkt, dass das Mess-Setup fehlerhaft ist.

 

[foo_1337]

Dann ist es zwecklos. Nur um des Messens willen zu messen ergibt keinen Sinn. Die Ergebnisse sind jedenfalls nicht aussagekräftig.

Doch, sind sie. Wieso sollten sie es nicht sein?

Sind sie nie, das liegt einfach in den grundsätzlichen IP-Mechanismen begründet.

Wir sind hier bei 1Gbit/s via UDP. Das schaffst du locker single stream. Wieso willst du das ständig in Frage stellen? Mit Mechanismen meinst du vermutlich eher die TCP Mechanismen

Wenn bei mehreren parallelen Streams ein schlechteres Ergebnis rauskommt, als bei einem Stream, dann weiß man direkt, dass das Mess-Setup fehlerhaft ist.

Nein, dann weiß man, dass der SoC in der Fritzbox einfach zu lahm ist.

Der TE soll einfach die UDP Messung machen und gut ist. Idealerweise macht er das 1x via LAN und 1x via WLAN. Leider wird er es mangels Equipment vermutlich nur via WLAN machen können.
Weitere Vorschläge von Dir, die für den TE nicht durchführbar sind, sind sicher hilfreich.

 

[riversource]

Wieso willst du das ständig in Frage stellen?

Ich habs gerade mit einer Fritz 5530 und einem Raspi 4 getestet:
LAN:
5530: 850 MBit/s single Stream; 950 MBit/s bei 10 Streams
Raspi: 950 MBit/s single Stream; 950 MBit/s bei 10 Streams

WLAN:
5530: 350 MBit/s single Stream; 480 MBit/s bei 10 Streams
Raspi: 520 MBit/s single Stream; 530 MBit/s bei 10 Streams

Zum Vergleich: Iperf3 gegen den Raspi: 950 MBit/s via LAN, 500 via WLAN. Beides mal mit 10 Streams.

Mit Mechanismen meinst du vermutlich eher die TCP Mechanismen

Nein, IP. Du testest ja auch via UDP, nicht nur TCP. Parallele Streams haben sowohl bei TCP als auch bei UDP Vorteile, siehe oben.

Ich kanns nur noch mal wiederholen:

• Die fritz ist als Gegenstelle nicht geeignet
• Parallele Streams sind niemals kontraproduktiv.

 

[blastinMot]

Nein kann in dem Fall nicht sein. Ich denke es liegt nicht am WLAN, sondern an der Messung oder der FB.

Denke ich auch.

Habe bei meinen Eltern folgendes Setup:

• 500er FTTH Tarif der Telekom
• Speedport Smart 4 im Erdgeschoss
• 1. Speed Home WLAN per Netzwerkkabel mit dem Smart 4 verbunden, diese SHW steht im Obergeschoss im Flur
• 2. Speed Home WLAN per Mesh WLAN mit der 2. SHW gekoppelt, steht nur einen Raum weiter (gegenüber von der 1. SHW im Flur)
• 1x PC per Netzwerkkabel an der 2. Speed Home WLAN

Merkwürdigerweise verbinden sich die SHW per WLAN nur noch mit ~400-450 Mbit miteinander laut der Konfig.-Oberfläche, trotz mittlerweile etwas besserer Platzierung (Netzwerkkabel zum Rechner etwas länger gemacht und 2. SHW dichter zur 1. SHW).
Diese ~400 Mbit aus der Oberfläche werden aber auch am Rechner erreicht.
Schwankt zwar etwas, aber passt.
Hatte auch schon mal annähernd die 500 Mbit am Rechner. Da war die WLAN Verbindung zwischen den SHW aber auch im Gigabitbereich.

Was viel mehr nervt ist der schwankende Ping am Rechner.
Per Netzwerkkabel zur 2. SHW verbunden (und dann per WLAN weiter zur 1. SHW) schwankt es zwischen 20-30ms, kurzzeitig auch mal ~60ms, minimal etwa 18ms.

Per Netzwerkkabel zur 1. SHW verbunden schaffe ich etwa 11-13ms zu dem jeweiligen Server meines Lieblingsspiels.
Für normales Surfen/Zocken/Streamen schon sehr gut.
Für Shooter muss dann doch manchmal das Kabel über den Flur.
Hoffe mit künftigen WLAN Standards gehts auch den Latenzen mal an den Kragen.

Bin aber erst im April wieder dort, also keine Tests möglich aktuell.

 

[cartridge_case]

Kabel verlegen ist keine Option.

Das ist immer eine Option. Die meisten wollen nur einfach nicht.

Ansonsten verstehe ich den Hintergrund der Frage nicht. Wenn du aktuelle WLAN-Hardware einsetzt, dann kannst du das Gigabit auch ausreizen, wenn nicht, dann nicht.

 

[blastinMot]

Ansonsten verstehe ich den Hintergrund der Frage nicht. Wenn du aktuelle WLAN-Hardware einsetzt, dann kannst du das Gigabit auch ausreizen, wenn nicht, dann nicht.

Hast du überhaupt mehr als den Eingangspost gelesen?
Er hat aktuelle Wifi 6 Hardware und sucht eine Möglichkeit ohne einen passenden Internetanschluss die WLAN Geschwindigkeit im Netzwerk zu testen. Was gibts da nicht zu verstehen?

 

[cartridge_case]

Was gibts da nicht zu verstehen?

Wofür? Wenn es dann, wenn die Leitung da ist, nicht ausreicht, kann man doch noch immer optimieren.

 

[blastinMot]

Wofür?

Manche Leute laufen erst los, wenn der Startschuss gefallen ist.
Andere Trainieren vorher und legen sich vorher schon das passende Equipment zu.

 

[cartridge_case]

Dann würde er LAN verlegen.

 

[foo_1337]

@riversource

Gammel Syno NAS vs Debian Mac Mini:
UDP Single Stream: 955Mbit/s
UDP 10 Parallele Streams: 934Mbit/s
TCP Single Stream: 946 Mbit/s
TCP 10 Parallele Streams: 889 Mbit/s

Ich kanns auch gerne Screenshotten. Es gibt nunmal Konstellationen, wo Multistream suboptimal ist. Generell braucht man, um 1 Gbit/s auszulasten, bei einigermaßen aktuellen Rechnern (Den miesen SoC im Syno NAS zähle ich dazu nicht, aber Multistream TCP ist noch katastrophaler) kein Multi Stream. Im LAN! Denn auch 10Gbit/s sind locker via TCP Single Stream drin. Bei 40Gbit/s oder gar 100Gbit/s wird es dann kritisch. Im WAN natürlich deutlich früher. Ich kann dir ab nächster Woche auch gerne Ergebnisse in diesen Bereichen liefern.

Nein, IP. Du testest ja auch via UDP, nicht nur TCP. Parallele Streams haben sowohl bei TCP als auch bei UDP Vorteile, siehe oben.

Es gibt seitens IP keine Bottlenecks, die Multistream erfordern. Ebensowenig bei UDP. Bei TCP halt schon, daher ist das kein IP "Problem".

Die fritz ist als Gegenstelle nicht geeignet

Für den Use Case hier durchaus. Aber du kannst ja dem TE gerne entsprechendes Messequipment vorbei bringen. Er freut sich sicher. Wir sind hier nicht in einer Idealwelt sondern müssen mit den vorhandenen Methoden auskommen. Dein eigener Test oben hat doch bereits bewiesen, dass die FB dafür ausreichend ist.
Der TE scheitert doch bereits daran, die Manpage von iperf zu lesen. Wie sehr wollen wir ihn noch verwirren?

Parallele Streams sind niemals kontraproduktiv

Bei miesen SoC eben schon. Proof siehe oben.

 

[spcqike]

Wofür? Wenn es dann, wenn die Leitung da ist, nicht ausreicht, kann man doch noch immer optimieren.

Ich sag mal, ich würde bei online gekauften Sachen auch testen wollen, ob sie für das was ich machen will ausreichen. Und wenn es nicht passt, retournieren.

Testen, bevor der Anschluss da ist, macht schon Sinn.

 

[cartridge_case]

ob sie für das was ich machen will ausreichen

Bei WLAN? Ach herrje.