@hed schrieb:

Swisscom drosselt nichts, aber TV und VoIP haben gegenüber dem restlichen Datenverkehr eine höhere Priorität (QoS).


Die IPerf(3)-Messungen zeigen “schwarz auf weiss” auf, dass der UDP-Datenverkehr in Downstream-Richtung auf rund 655 kbit/s gedrosselt wird. Unabhängig von den aktuellen IPerf(3)-Messungen haben auch weitere Swisscom-Glasfaser-Privatkunden diese UDP-Drosselung (100KBytes/sec => rund 1 bis 2 MBit/s) mit der Internet-Box von Swisscom festgestellt:

https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658

QoS kommt erst zur Wirkung, wenn sich die Datenpakete in einer Netzwerkkomponente stauen. Im aktuellen Fall wäre dies der Fall, wenn in Downstream-Richtung der Datenverkehr > 100 MBit/s beträgt, was mit Swisscom TV allein nicht erreicht wird. Die IPerf(3)-Messungen wurden bewusst mit einem UDP-Datenstrom von 95 statt 100 MBit/s durchgeführt, damit sich in keiner Netzwerkkomponente ein Warteschlangestau bilden kann und das QoS die Messung verfälschen könnte.

Für die IPerf(3)-Messungen muss die Glasfaserleitung unbelastet sein (Leerlauf). Der Mess-Computer sollte der einzige Heimnetzteilnehmer an der Internet-Box sein.

Hallo @GrandDixence

“Unabhängig von den aktuellen IPerf(3)-Messungen haben auch weitere Swisscom-Glasfaser-Privatkunden diese UDP-Drosselung (100KBytes/sec => rund 1 bis 2 MBit/s) mit der Internet-Box von Swisscom festgestellt”

\=> eventuell liegt hier der Grund, dass ich noch immer auf einen Anruf / Rückfruf von My Service warte. Diese Woche bin ich leider nicht ganz so flexibel, ich hoffe dass ich Donnerstags zu weiteren Tests komme und einem Anruf mit Swisscom komme.

“Für die IPerf(3)-Messungen muss die Glasfaserleitung unbelastet sein (Leerlauf). Der Mess-Computer sollte der einzige Heimnetzteilnehmer an der Internet-Box sein.”

Ich werde dieses Szenario nochmals “herstellen” und dann testen. Danke nochmals für die detaillierten Infos und Hilfe!

“Ist die Firmware der Swisscom Internet-Box auf dem aktuellen Stand?”

Ja, ich habs jeweils auch mit Beta-Versionen getestet. Werde heute Abend die Versionen auf meiner Internet Box nachschauen und dann hier hinzufügen.~

Edit 18:39 Uhr:

Meine “Installierte Firmware-Version”: 07.50.41/07.50.35/1003

Hallo @GrandDixence

Hab nun grad mal kurz “Spasseshalber” im Zug mit Teathering und meinem Laptop getestet. Gleiches Resultat, nach dem ersten durchlauf wird die Leitung auf 655kbit/s gedrosselt.

Wenn ich den Parameter -u weglasse komme ich auf wesentlich höhere Speeds. Also offenbar macht das Swisscom einfach generell, dass UDP extrem gedrosselt wird.

iperf3 -u -R -c ping.online.net -b 95M -l 512

und noch immer 655kbit/s?😃

IPerf(3)-Messungen über das Mobilfunknetz mit einer Swisscom SIM-Karte zeigen in Downstream-Richtung bei einer UDP-Paketgrösse von 8 Kilobyte hohe Paketverlustraten auf. Bei IPerf(3) ist die Default-/Standardeinstellung der UDP-Paketgrösse 8 Kilobyte.

Erst eine Reduktion der UDP-Paketgrösse mit dem IPerf-Parameter “-l” deutlich unter den MTU-Wert (Ethernet: 1500 Byte, PPPoE: < 1493 Byte):

https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

führt zu akzeptablen Paketverlustraten (< 1 %). Grund für dieses Verhalten dürfte die IP-Fragmentierung sein:

https://de.wikipedia.org/wiki/IP-Fragmentierung

Müssen IPv4-Pakete von Netzwerkkomponenten fragmentiert werden (Empfangsseite ein grösserer MTU-Wert als auf der Sendeseite) führt die Fragmentierung und die anschliessende Zusammensetzung/Reassemblierung der IPv4-Pakete zu Performance-Verlusten. Deshalb akzeptieren einige IP-Router/Firewalls aus Performance-Gründen und als Schutz vor DoS-Attacken keine fragmentierte IPv4-Pakete:

https://en.wikipedia.org/wiki/IP_fragmentation_attack

https://de.wikipedia.org/wiki/Denial_of_Service

In IPv6 dürfen IP-Router keine IP-Pakete fragmentieren. TCP-Übertragungen passen die IP-Paketgrösse dem kleinsten MTU des Übertragungsweg an:

https://de.wikipedia.org/wiki/Transmission_Control_Protocol

UDP verfügt über keinen Mechanismus für die Erkennung des kleinsten MTU im Übertragungsweg.

Wieso beim Swisscom-Glasfaseranschluss die MTU nicht 1500 Byte beträgt, ist mir ein Rätsel. Setzt die Swisscom PPP für den Glasfaseranschluss ein?

https://de.wikipedia.org/wiki/Point-to-Point_Protocol

Für die UDP-Datenübertragung ist der Internetanschluss über das Fernsehkabelnetz (EuroDOCSIS) im Vorteil. Meine IPerf(3)-Messungen am EuroDOCSIS-Kabelmodem in Downstream-Messungen mit 65507 Byte grossen UDP-Paketen zeigen normale Paketverlustraten um die 1 %. UDP-Pakete dürfen maximal 65507 Byte gross sein:

https://de.wikipedia.org/wiki/User_Datagram_Protocol

Hallo @akai

Ich bin mir sicher, dass Du mir mit Deinem Post was sagen willst. Leider weiss ich aber nicht was.

\=> Gehst Du davon aus, dass die Drosselung von UDP (egal bei welcher Paketgrösse) garantiert KEINEN Einfluss auf meine Probleme mit XBOX Live beim Spiel Fifa im Modus Ultimate Team hat?

Falls ja wäre das gut zu wissen (und eventuell auch warum) damit ich nicht am falschen Ort suche.

Merci und Gruss

Hallo @GrandDixence

Einmal mehr vielen! Dank! für Deine ausführliche und mit Links belegte Antwort. Ich hoffe, dass ich mit all diesen Informationen mit dem Support von Swisscom eine Lösung finde.

Soweit ich mich erinnere hat die XBOX One bei MTU den Wert 1480. Eventuell harmonisiert hier ja etwas wirklich überhaupt nicht.

Ich kann mich erinnern, dass ich “eine gewisse Zeit” mal keinerlei Probleme beim online Spielen hatte. Leider weiss ich aber nicht mehr genau wann dies der Fall war. Grob gesagt ca. 1 Monat während der Zeit von Oktober - Februar, leider keine Ahnung wann genau es war (damals noch via DSL)

Ich hoffe, dass ich mit Swisscom eine Lösung finde, ansonsten hab ich nun ein paar Dinge (UDP throttling und MTU) welche ich mit dem Support meines neuen Anbieters garantiert vorab prüfen werde. Ich hoffe dass dies nicht ein generelles Fibre Problem ist, kann es mir aber nicht vorstellen.

(Worst Case zeigt sich, dann, dass dies alles gar keinen Einfluss hatte und am Ende doch Micorosoft und EA mit Ihren Servern die Ursache sind, aber im Moment hab ich noch “Hoffnung”).

Es sieht danach aus, als würde Swisscom für den Glasfaseranschluss PPPoE einsetzen:

http://documents.swisscom.com/product/1000260-Connectivity_Geraete_/Documents/Spezifikationen/Centro_Business_PPPoE_Passthrough-de.pdf

https://de.wikipedia.org/wiki/PPP_over_Ethernet

Der Einsatz von PPPoE führt gemäss den IPerf(3)-Messungen bei grossen UDP-Paketen (> ca. 1400 Byte) zu massiven Paketverlusten. Abhilfe gegen das “grosse UDP-Pakete-Problem” bietet:

a) Einsatz eines Glasfaseranschluss von einem Drittanbieter ohne Routerzwang

b) ODER die Realisierung eines PPPoE-freien Glasfaseranschlusses: Entfernung der Internet-Box von Swisscom und der Einsatz eines Medienkonverter Kupfer-Ethernet <-> Glasfaser-Ethernet

https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658

https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glasfaser-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171#M1056

Ich bezweifle, dass für die Games grosse UDP-Pakete > 1400 Byte verwendet werden und somit gar keine Massnahme a) oder b) erforderlich ist. Gewissheit bieten hier nur die Analyse der Netzwerkdatenverkehrsaufzeichnungen mit Wireshark:

https://www.wireshark.org/

Wenn die IPerf(3)-Messungen mit UDP-Paketen < 1400 Byte in Downstream-Richtung die einwandfreie Funktion des Glasfaseranschlusses belegen (Paketverlustrate < 0.01 % und Jitter < 1 Millisekunde) UND die Games keine UDP-Pakete > 1400 Byte verwenden, so liegt der Ball wieder beim Netzwerkbetreiber (Swisscom), ihren Peering-Partnern und den Game Server-BetreiberInnen.

@GrandDixence

FTTH hat noch ein VLAN drauf. Darum sollten eigentlich noch 4 Byte abgehen.

Bei Privatkunden wird DHCP eingesetzt.

Theoretisch ist die maximale MTU dort also 1496

Ich habe eine PPPoE Termination über FTTH und VLAN. Da hätte ich 1492. Effextiv aber nur 1488 wegen dem VLAN.

So ist es bei mir.

Bestätigt hat dies aber noch nie jemand von Swisscom 😉 Ich habe nur mal gesagt das man ja eigentlich die Konfig Sheets für Firewals entsprechend anpassen sollte.

Es wäre cool jemand könnte mal die effektive MTU an seinem FTTH Privatkundenanschluss testen.

http://www.tp-link.com/en/article/?faqid=190

tiibor

Ich wollte dass du einfach mal Copy & Paste machst und selber feststellst. Das es sich nur um einen Messfehler handelt. Weshalb -l x so wichtig ist bei UDP, hat der Kollege oben schon erklärt.

Nun ich bin nur mit einer kl. Bandbreite gesegnet. Aber ich denke mit fine tuning der Werte -b und -l wirst nun auch du das max. erreichen. Ausser es gibt wirklich ein L1 Problem vor Ort. Aber nach deiner Beschreibung kann man dies ausschliessen.

Weil auch das Traceroute/MTR zu easo.ea.com i.o ist, d.h kein Routing Problem sichtbar ist. Kann man dies definitv aussschliessen.

Auch das du nicht geschrieben hast, dass alles mit der Box langsam ist. Sondern eher nur ein Game im spezielen. Deutet auf ein Problem beim Spieleserver selber hin! Mangels HW kann ich dazu aber nichts genaues aussagen.

Nun ich würde nochmals ein Trouble Ticket erstellen mit den ganzen neuen erkenntnissen beim Game Anbieter und schauen, ob mehr kommt diesmal. Wenn Sie wieder schreiben alles ok. frag wie du dies selber überprüfen kannst?

iperf3 -u -R -c ping.online.net -b 20M

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.01 sec 192 KBytes 1.56 Mbits/sec 10.698 ms 252/276 (91%)
[ 4] 1.01-2.01 sec 80.0 KBytes 655 Kbits/sec 5.897 ms 296/306 (97%)
[ 4] 2.01-3.01 sec 80.0 KBytes 655 Kbits/sec 3.433 ms 295/305 (97%)
[ 4] 3.01-4.01 sec 80.0 KBytes 654 Kbits/sec 2.143 ms 295/305 (97%)
[ 4] 4.01-5.01 sec 80.0 KBytes 656 Kbits/sec 1.435 ms 295/305 (97%)
[ 4] 5.01-6.01 sec 80.0 KBytes 655 Kbits/sec 0.986 ms 295/305 (97%)
[ 4] 6.01-7.01 sec 80.0 KBytes 655 Kbits/sec 0.741 ms 295/305 (97%)
[ 4] 7.01-8.01 sec 80.0 KBytes 655 Kbits/sec 0.810 ms 296/306 (97%)
[ 4] 8.01-9.01 sec 80.0 KBytes 655 Kbits/sec 0.855 ms 295/305 (97%)
[ 4] 9.01-10.01 sec 80.0 KBytes 655 Kbits/sec 0.569 ms 295/305 (97%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.01 sec 23.8 MBytes 20.0 Mbits/sec 0.569 ms 2909/3023 (96%)
[ 4] Sent 3023 datagrams

iperf Done.

iperf3 -u -R -c ping.online.net -b 20M -l 1420

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.31 MBytes 11.0 Mbits/sec 0.848 ms 506/1477 (34%)
[ 4] 1.00-2.00 sec 1.24 MBytes 10.4 Mbits/sec 0.795 ms 895/1811 (49%)
[ 4] 2.00-3.00 sec 1.24 MBytes 10.4 Mbits/sec 6.828 ms 903/1822 (50%)
[ 4] 3.00-4.00 sec 1.25 MBytes 10.4 Mbits/sec 0.730 ms 829/1749 (47%)
[ 4] 4.00-5.00 sec 1.25 MBytes 10.5 Mbits/sec 0.829 ms 789/1709 (46%)
[ 4] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 0.831 ms 837/1757 (48%)
[ 4] 6.00-7.00 sec 1.25 MBytes 10.4 Mbits/sec 0.764 ms 863/1783 (48%)
[ 4] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0.707 ms 878/1798 (49%)
[ 4] 8.00-9.00 sec 1.25 MBytes 10.5 Mbits/sec 0.783 ms 806/1726 (47%)
[ 4] 9.00-10.00 sec 1.25 MBytes 10.4 Mbits/sec 0.772 ms 833/1753 (48%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 1.481 ms 8259/17606 (47%)
[ 4] Sent 17606 datagrams

Host Loss% Snt Last Avg Best Wrst StDev
….
14. easo.ea.com 0.0% 310 111.7 111.7 109.9 149.5 2.8


@Tux0ne schrieb:

Es wäre cool jemand könnte mal die effektive MTU an seinem FTTH Privatkundenanschluss testen.

http://www.tp-link.com/en/article/?faqid=190


Mit dem Test gem. Link als iway.ch Privatkunde (über DHCP) Glasfasernetz EWZ erhalte ich 1472, demnach der optimale Wert liegt bei 1472+28= MTU 1500.? Wozu das auch immer gut sein soll…

Dann hast du auf dem ew Zürinet kein.11q tagging und als Access Technologie DHCP, demnach ist für IPv4 1500 gut.

Ich frage aber eigentlich nach FTTH Swisscom Kunden oder von mir aus einer auf dem bbcs-f Netz.

Dort hast du.11q tagging und die MTU kann gar nicht 1500 sein.

Also nur das man sich das mal bewusst ist wenn man Probleme bekommt. Nicht mal bezogen auf diesen Thread sondern ganz allgemein.


@Tux0ne schrieb:

@GrandDixence

FTTH hat noch ein VLAN drauf. Darum sollten eigentlich noch 4 Byte abgehen.

Theoretisch ist die maximale MTU dort also 1496


Die Aussage ist nicht ganz korrekt: Beim Einsatz von VLAN nach IEEE 802.1Q über Ethernet bleibt die maximale Nutzdatenmenge 1500 Byte und somit das MTU auf 1500 Byte. VLAN nach IEEE 802.1Q über Ethernet hat keinen Einfluss auf den MTU-Wert. Das Ethernet Frame wird beim Einsatz von VLAN einfach 4 Byte grösser (1522 Byte statt 1518 Byte):

https://de.wikipedia.org/wiki/Virtual_Local_Area_Network

https://de.wikipedia.org/wiki/IEEE_802.1Q

Nur beim Einsatz von “Double tagging” verkleinert sich die MTU auf 1496 beim Einsatz von VLAN nach IEEE 802.1Q über Ethernet:

https://en.wikipedia.org/wiki/IEEE_802.1Q

http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html#frame2

@GrandDixence

Ja da hast du recht. Ich kann das so nicht auf RES Anschlüsse übertragen. Da habe ich einen Denkfehler gemacht.

Ich schaue mal bei Gelegenheit wieso ich in meinem Setup (my KMU Office Dual Session WAN PPPoE Passthrough) max 1488 habe.

Was das betrifft ist die Dokumentation schlicht nicht vorhanden. Muss man selber schauen wo man bleibt 😉

Hallo @akai

Vielen Dank für Ihre Antwort und Erklärung. Hast du es mit diesen Parametern ausgeführt (Setup: Nur PC direkt am Router als einziges Gerät):

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Verbindung zum Host debit.k-net.fr, Port 5201
Reverse-Modus, Remote-Host debit.k-net.fr sendet
[ 4] lokaler 192.168.1.107 Port 57470 verbunden mit 178.250.209.22 Port 5201
[ ID] Intervall-Übertragungsbandbreiten-Jitter-Verlust/Gesamtzahl der Datagramme
[ 4] 0,00-1,00 Sek. 9,00 MByte 75,5 Mbit/Sek. 0,012 ms 7966/26392 (30 %)
[ 4] 1,00–2,00 Sek. 8,16 MByte 68,5 Mbit/Sek. 0,011 ms 6584/23303 (28 %)
[ 4] 2,00–3,00 Sek. 9,29 MByte 78,0 Mbit/Sek. 0,009 ms 4195/23226 (18 %)
[ 4] 3,00-4,00 Sek. 9,23 MByte 77,4 Mbit/Sek. 0,009 ms 4247/23149 (18 %)
[ 4] 4,00-5,00 Sek. 8,82 MByte 74,0 Mbit/Sek. 0,009 ms 5382/23451 (23 %)
[ 4] 5,00-6,00 Sek. 9,71 MByte 81,4 Mbit/Sek. 0,005 ms 3314/23197 (14 %)
[ 4] 6,00-7,00 Sek. 9,35 MByte 78,4 Mbit/Sek. 0,008 ms 3859/23006 (17 %)
[ 4] 7,00-8,00 Sek. 9,53 MByte 79,9 Mbit/Sek. 0,009 ms 3707/23221 (16 %)
[ 4] 8,00–9,00 Sek. 9,25 MByte 77,6 Mbit/Sek. 0,008 ms 4206/23160 (18 %)
[ 4] 9,00–10,00 Sek. 9,65 MByte 80,9 Mbit/Sek. 0,008 ms 3523/23277 (15 %)
- - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervall-Übertragungsbandbreiten-Jitter-Verlust/Gesamtzahl der Datagramme
[ 4] 0,00-10,00 Sek. 115 MByte 96,7 Mbit/Sek. 0,005 ms 46983/236021 (20 %)
[ 4] 236021 Datagramme gesendet

iperf Fertig.

Manchmal hatte ich jedoch auch ein seltsames Verhalten wie dieses (es könnte aber auch am Server liegen):

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Verbindung zum Host debit.k-net.fr, Port 5201
Reverse-Modus, Remote-Host debit.k-net.fr sendet
[ 4] lokaler 192.168.1.107 Port 59573 verbunden mit 178.250.209.22 Port 5201
iperf3: OUT OF ORDER – eingehendes Paket = 50 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 51 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 52 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 53 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 54 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 55 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 56 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 57 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 58 und empfangenes Paket = 0 UND SP = 66
iperf3: OUT OF ORDER – eingehendes Paket = 59 und empfangenes Paket = 0 UND SP = 66
[ ID] Intervall-Übertragungsbandbreiten-Jitter-Verlust/Gesamtzahl der Datagramme
[ 4] 0,00-1,01 Sek. 6,43 MByte 53,2 Mbit/Sek. 0,011 ms 12675/25830 (49 %)
[ 4] 1,01–2,00 Sek. 5,10 MByte 43,4 Mbit/Sek. 0,019 ms 12430/22881 (54 %)
[ 4] 2,00–3,00 Sek. 5,09 MByte 42,5 Mbit/Sek. 0,012 ms 11220/21650 (52 %)
[ 4] 3,00-4,00 Sek. 6,48 MByte 54,6 Mbit/Sek. 0,017 ms 11783/25056 (47 %)
[ 4] 4,00-5,01 Sek. 5,81 MByte 48,2 Mbit/Sek. 0,010 ms 11317/23212 (49 %)
[ 4] 5,01-6,01 Sek. 4,56 MByte 38,3 Mbit/Sek. 0,014 ms 13383/22728 (59 %)
[ 4] 6,01–7,01 Sek. 5,16 MByte 43,3 Mbit/Sek. 0,135 ms 13060/23630 (55 %)
[ 4] 7,01-8,00 Sek. 6,07 MByte 51,2 Mbit/Sek. 0,290 ms 10585/23018 (46 %)
[ 4] 8,00-9,00 Sek. 4,36 MByte 36,7 Mbit/Sek. 0,016 ms 13178/22105 (60 %)
[ 4] 9,00–10,00 Sek. 6,34 MByte 53,0 Mbit/Sek. 0,034 ms 11006/23995 (46 %)
- - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervall-Übertragungsbandbreiten-Jitter-Verlust/Gesamtzahl der Datagramme
[ 4] 0,00-10,00 Sek. 115 MByte 96,1 Mbit/Sek. 0,034 ms 120637/234105 (52 %)
[ 4] 234105 Datagramme gesendet
[SUMME] 0,0–10,0 Sek. 10 Datagramme wurden außerhalb der Reihenfolge empfangen

iperf Fertig.

Leider habe ich keine Ahnung, wie es genau mit den Paketen und deren Größe beim Online-Spielen über XBOX One und Fifa Ultimate aussieht. Gestern Abend habe ich es noch einmal versucht und dabei ist mir aufgefallen, dass das Spiel in bestimmten Situationen stärker einfriert als in anderen. Möglicherweise handelt es sich dabei um Situationen, in denen mehr Verkehr ankommt, oder größere Pakete, keine Ahnung.

Ich werde sehen, was der Support sagt. Möglicherweise gibt es noch mehr Möglichkeiten zum Testen. Außerdem scheinen meine Signalpegel immer noch seltsam zu sein. Wenn das alles nicht hilft, werde ich parallel einen anderen Anbieter testen. Wenn es bei diesem anderen Anbieter problemlos funktioniert, kann ich Swisscom zumindest „zeigen“, dass es bei Ihnen liegt. Wenn es nicht hilft, gebe ich auf. (Muss mal nachschauen, vielleicht kann ich per WLan vorher mal einen anderen Anbieter vom Nachbarn testen, WLAN ist nicht ideal, wäre aber interessant)

bearbeiten: Warum ist die Rechtschreibprüfung meines Browsers in diesem Forum nicht aktiv? Habe dieses Problem nirgendwo sonst gehabt…

Originalsprache (Luxemburgisch) anzeigen

@Tux0ne

MTU hab ich getestet, komme via Deinem Link auf 1472: Sprich 1500. Via dem Link von @XT komme ich auf auf “The maximum MTU size for 178.199.89.xxx is: 1500”

Aber das hat sich ja eventuell eh schon erledigt.

@GrandDixence

“Wenn die IPerf(3)-Messungen mit UDP-Paketen < 1400 Byte in Downstream-Richtung die einwandfreie Funktion des Glasfaseranschlusses belegen (Paketverlustrate < 0.01 % und Jitter < 1 Millisekunde)”

Ich denke Jitter ist in Ordnung, Paketverlustrate hingegen nicht:

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Connecting to host debit.k-net.fr, port 5201
Reverse mode, remote host debit.k-net.fr is sending
[ 4] local 192.168.1.107 port 60488 connected to 178.250.209.22 port 5201
iperf3: OUT OF ORDER - incoming packet = 58 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 59 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 60 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 61 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 62 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 63 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 64 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 65 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 66 and received packet = 0 AND SP = 109
iperf3: OUT OF ORDER - incoming packet = 67 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 68 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 69 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 70 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 71 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 72 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 73 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 74 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 75 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 76 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 77 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 78 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 79 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 80 and received packet = 0 AND SP = 127
iperf3: OUT OF ORDER - incoming packet = 81 and received packet = 0 AND SP = 127
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 8.46 MBytes 71.0 Mbits/sec 0.034 ms 8660/25971 (33%)
[ 4] 1.00-2.00 sec 9.35 MBytes 78.5 Mbits/sec 0.009 ms 4052/23208 (17%)
[ 4] 2.00-3.00 sec 10.1 MBytes 84.5 Mbits/sec 0.010 ms 2544/23179 (11%)
[ 4] 3.00-4.00 sec 9.69 MBytes 81.2 Mbits/sec 0.015 ms 3218/23063 (14%)
[ 4] 4.00-5.00 sec 9.84 MBytes 82.5 Mbits/sec 0.012 ms 3136/23288 (13%)
[ 4] 5.00-6.00 sec 9.08 MBytes 76.2 Mbits/sec 0.021 ms 4569/23171 (20%)
[ 4] 6.00-7.00 sec 9.78 MBytes 82.0 Mbits/sec 0.009 ms 3125/23146 (14%)
[ 4] 7.00-8.00 sec 9.69 MBytes 81.2 Mbits/sec 0.010 ms 3688/23527 (16%)
[ 4] 8.00-9.00 sec 9.44 MBytes 79.2 Mbits/sec 0.010 ms 3598/22923 (16%)
[ 4] 9.00-10.00 sec 9.52 MBytes 79.9 Mbits/sec 0.009 ms 3748/23244 (16%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 115 MBytes 96.4 Mbits/sec 0.005 ms 40338/235379 (17%)
[ 4] Sent 235379 datagrams
[SUM] 0.0-10.0 sec 24 datagrams received out-of-order

iperf Done.

“UND die Games keine UDP-Pakete > 1400 Byte verwenden, so liegt der Ball wieder beim Netzwerkbetreiber (Swisscom), ihren Peering-Partnern und den Game Server-BetreiberInnen.”

Da hab ich leider keine Ahnung. Wenn ich mit aber das Verhalten im Spiel anschauen, dann ist es nicht immer gleich schlimm. Kann sein dass es nur bei Spielzügen auftaucht bei denen eventuell auch mehr Informationen fliessen?

Siehe zwei Videos (sind links zu OneDrive):

https://1drv.ms/v/s!AkNoK6Dl-AMqgRJ8yLZHuT9Siu-c

https://1drv.ms/v/s!AkNoK6Dl-AMqgRHPredIY2j4JBuA (in diesem Video deutlich bei Sekunde ~ 16)

Man sieht in diesen Videos das Ruckeln teilweise ziemlich extrem. Beim Spielen lässt sich das wohl am ehesten mit Input Lags beschreiben. Es fühlt sich an als ob alles zu träge wäre, teilweise bis hin zu “fremd gesteuert”.

    tiibor


    tiibor schrieb:

    Ich denke, Jitter ist in Ordnung, Paketverlustrate hingegen nicht:

    iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
    Verbindung zum Host debit.k-net.fr, Port 5201
    Reverse-Modus, Remote-Host debit.k-net.fr sendet
    [ 4] lokaler 192.168.1.107 Port 60488 verbunden mit 178.250.209.22 Port 5201
    iperf3: OUT OF ORDER – eingehendes Paket = 58 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 59 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 60 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 61 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 62 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 63 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 64 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 65 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 66 und empfangenes Paket = 0 UND SP = 109
    iperf3: OUT OF ORDER – eingehendes Paket = 67 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 68 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 69 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 70 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 71 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 72 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 73 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 74 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 75 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 76 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 77 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 78 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 79 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 80 und empfangenes Paket = 0 UND SP = 127
    iperf3: OUT OF ORDER – eingehendes Paket = 81 und empfangenes Paket = 0 UND SP = 127
    [ ID] Intervall-Übertragungsbandbreiten-Jitter-Verlust/Gesamtzahl der Datagramme
    [ 4] 0,00-1,00 Sek. 8,46 MByte 71,0 Mbit/Sek. Wie bereits mitgeteilt, lässt sich mit Wireshark relativ schnell und einfach die vom Game verwendete UDP-Paketgrösse feststellen:

    Wireshark_UDP_Paketgroesse.png

    Hier ein Beispiel, wie die IPerf3-Messung mit UDP-Paketen in Downstream-Richtung aussehen sollte (PC direkt an EuroDOCSIS-Kabelmodem):

    UDP-Messung des Downstream/Download (100 MBit/s)

    iperf3 -u -R -c debit.k-net.fr -b 100M

    Connecting to host debit.k-net.fr, port 5201
    Reverse mode, remote host debit.k-net.fr is sending
    [ 4] local 77.57.166.140 port 40131 connected to 178.250.209.22 port 5201
    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-1.00 sec 11.2 MBytes 94.2 Mbits/sec 0.719 ms 0/1437 (0%)
    [ 4] 1.00-2.00 sec 11.9 MBytes 100 Mbits/sec 0.703 ms 0/1526 (0%)
    [ 4] 2.00-3.00 sec 11.9 MBytes 100 Mbits/sec 0.688 ms 0/1527 (0%)
    [ 4] 3.00-4.00 sec 11.9 MBytes 99.9 Mbits/sec 0.704 ms 0/1524 (0%)
    [ 4] 4.00-5.00 sec 11.9 MBytes 100 Mbits/sec 0.704 ms 0/1527 (0%)
    [ 4] 5.00-6.00 sec 11.9 MBytes 100 Mbits/sec 0.712 ms 0/1526 (0%)
    [ 4] 6.00-7.00 sec 11.9 MBytes 100 Mbits/sec 0.670 ms 0/1526 (0%)
    [ 4] 7.00-8.00 sec 11.9 MBytes 99.9 Mbits/sec 0.699 ms 0/1525 (0%)
    [ 4] 8.00-9.00 sec 11.9 MBytes 100 Mbits/sec 0.709 ms 0/1527 (0%)
    [ 4] 9.00-10.00 sec 11.9 MBytes 100 Mbits/sec 0.707 ms 0/1526 (0%)


    [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    [ 4] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.613 ms 0/15262 (0%)
    [ 4] Sent 15262 datagrams

    iperf Done.

    Originalsprache (Englisch) anzeigen

    Ist das gesamte Heimnetzwerk Gigabit-Ethernet (1000 MBit/s) tauglich? Sind alle Ethernet-Kabel im Heimnetzwerk mit “Cat. 5e” oder höher beschriftet (z.B. “Cat. 6” oder “Cat. 7”)? Sind alle Netzwerkkomponenten im Heimnetzwerk (z.B. Switch) Gigabit-Ethernet tauglich? Weist Windows auf dem Mess-PC die Nutzung vom Gigabit-Ethernet-Modus (1000 MBit/s) aus?

    https://www.swisscom.ch/de/privatkunden/hilfe/loesung/heimnetzwerk-zu-langsam.html

    https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-Computer/Ethernet-Problem/td-p/399781