Glasfaser: Down langsamer als Up

[tiibor]

Hoi @GrandDixence

Interessant danke. Dann muss ich das wirklich mit dem Swisscom Support abklären. Hoffe ich finde hier eine gute Lösung. (Heute konnte ich leider die Zeit nicht frei schaufeln, aber nächste Woche passt ja auch noch).

Gruss und Euch allen ein schönes Weekend

[hed]

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

[tiibor]

Hallo @hed

Wenn ich meine Werte mit iperf anschaue dann scheint offensichtlich etwas nicht zu stimmen. Ich werde bei Gelegeneit mal testen wie es aussieht wenn ich:

- Alles neu starte

- PC direkt an der Internet Box als einziges Gerät angehängt habe (auch ohne Telefon)

Aber parallel werde ich mit Swisscom schauen, die sollten ja wissen was ich machen kann. Eventuell liegts ja auch an meinem Profil. (Als HD aufkam war meine Leitung in der damaligen Wohnung eigentlich zu knapp. Damals konnte man beim Support erbitten, dass was speziell eingestellt wurde und hatte dann trotzdem HD-Sender. 

Wer weiss, eventuell hat sich hier trotz den vielen Wechseln meiner Produkte von Swisscom was durchgeschleift. Oder es ist sonst irgendwas.)

Immerhin habe ich ein Indiz wo ich noch was verbessern kann/muss

[GrandDixence]

---

@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://supportcommunity.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397...

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.

[GrandDixence]

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

https://www.swisscom.ch/de/privatkunden/hilfe/loesung/firmware-aktualisierungen-fuer-ihre-internet-b...

[tiibor]

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

[tiibor]

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.

[akai]

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

und noch immer 655kbit/s?  :smileyhappy:

[GrandDixence]

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

[tiibor]

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

[tiibor]

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").

[GrandDixence]

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...

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://supportcommunity.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397...

https://supportcommunity.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glasfaser-Router-%C3...

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.

[Tux0ne]

@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

[akai]

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?

Spoiler

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.

Spoiler

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

Spoiler

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

[CHnuschti]

---

@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 ...

[Tux0ne]

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.

[GrandDixence]

---

@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

[XT]

MTU Test
Fiber DHCP Privatabo

http://www.letmecheck.it/mtu-test.php

The maximum MTU size is: 1500

[Tux0ne]

@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 😉

[tiibor]

Hallo @akai

Danke für Deine Antwort und Erklärung. Habs mal mit diesen Parametern (setup: Nur PC direkt am Roter als einziges Gerät) laufen lassen:

Spoiler

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 57470 connected to 178.250.209.22 port 5201
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 9.00 MBytes 75.5 Mbits/sec 0.012 ms 7966/26392 (30%)
[ 4] 1.00-2.00 sec 8.16 MBytes 68.5 Mbits/sec 0.011 ms 6584/23303 (28%)
[ 4] 2.00-3.00 sec 9.29 MBytes 78.0 Mbits/sec 0.009 ms 4195/23226 (18%)
[ 4] 3.00-4.00 sec 9.23 MBytes 77.4 Mbits/sec 0.009 ms 4247/23149 (18%)
[ 4] 4.00-5.00 sec 8.82 MBytes 74.0 Mbits/sec 0.009 ms 5382/23451 (23%)
[ 4] 5.00-6.00 sec 9.71 MBytes 81.4 Mbits/sec 0.005 ms 3314/23197 (14%)
[ 4] 6.00-7.00 sec 9.35 MBytes 78.4 Mbits/sec 0.008 ms 3859/23006 (17%)
[ 4] 7.00-8.00 sec 9.53 MBytes 79.9 Mbits/sec 0.009 ms 3707/23221 (16%)
[ 4] 8.00-9.00 sec 9.25 MBytes 77.6 Mbits/sec 0.008 ms 4206/23160 (18%)
[ 4] 9.00-10.00 sec 9.65 MBytes 80.9 Mbits/sec 0.008 ms 3523/23277 (15%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 115 MBytes 96.7 Mbits/sec 0.005 ms 46983/236021 (20%)
[ 4] Sent 236021 datagrams

iperf Done.

Teilweise hatte ich aber auch ein seltsames Verhalten wie dieses hier (kann aber auch am Server liegen):

Spoiler

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 59573 connected to 178.250.209.22 port 5201
iperf3: OUT OF ORDER - incoming packet = 50 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 51 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 52 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 53 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 54 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 55 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 56 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 57 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 58 and received packet = 0 AND SP = 66
iperf3: OUT OF ORDER - incoming packet = 59 and received packet = 0 AND SP = 66
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.01 sec 6.43 MBytes 53.2 Mbits/sec 0.011 ms 12675/25830 (49%)
[ 4] 1.01-2.00 sec 5.10 MBytes 43.4 Mbits/sec 0.019 ms 12430/22881 (54%)
[ 4] 2.00-3.00 sec 5.09 MBytes 42.5 Mbits/sec 0.012 ms 11220/21650 (52%)
[ 4] 3.00-4.00 sec 6.48 MBytes 54.6 Mbits/sec 0.017 ms 11783/25056 (47%)
[ 4] 4.00-5.01 sec 5.81 MBytes 48.2 Mbits/sec 0.010 ms 11317/23212 (49%)
[ 4] 5.01-6.01 sec 4.56 MBytes 38.3 Mbits/sec 0.014 ms 13383/22728 (59%)
[ 4] 6.01-7.01 sec 5.16 MBytes 43.3 Mbits/sec 0.135 ms 13060/23630 (55%)
[ 4] 7.01-8.00 sec 6.07 MBytes 51.2 Mbits/sec 0.290 ms 10585/23018 (46%)
[ 4] 8.00-9.00 sec 4.36 MBytes 36.7 Mbits/sec 0.016 ms 13178/22105 (60%)
[ 4] 9.00-10.00 sec 6.34 MBytes 53.0 Mbits/sec 0.034 ms 11006/23995 (46%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 115 MBytes 96.1 Mbits/sec 0.034 ms 120637/234105 (52%)
[ 4] Sent 234105 datagrams
[SUM] 0.0-10.0 sec 10 datagrams received out-of-order

iperf Done.

Ich hab leider keine Ahnung wie genau es mit den Paketen und deren Grösse beim online Spielen via XBOX One und Fifa Ultimate aussieht. Gestern Abend habe ichs mal wieder gewagt, und da ist mir aufgefallen, dass das Spiel in gewissen Situationen mehr stockt als in andern. Eventuell sind das Situationen in welchen mehr Traffic kommt, oder grössere Pakete, keine Ahnung.

Ich schaue mal was der Support meint. Eventuell gibt es ja noch mehr Möglichkeiten zum testen. Auch scheinen meine Signalpegel ja noch immer seltsam. Falls das alles nichts nützt werde ich parallel einen anderen Provider testen. Falls es bei diesem anderen Providern ohne Probleme funktioniert kann ich Swisscom wenigstens "zeigen" dass es an Ihnen liegt. Falls es nichts nützt gebe ich auf. (Muss mal schauen, eventuell kann ich ja von einem Nachbarn via WLan einen anderen Provider vorab testen, WLAN ist zwar nicht ideal, aber wäre interessant)

Edit: Warum ist in diesem Forum eigentlich die Rechtschreibeprüfung meines Browsers nicht aktiv? Habe dieses Problem sonst nirgends...