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
Swisscom drosselt nichts, aber TV und VoIP haben gegenüber dem restlichen Datenverkehr eine höhere Priorität (QoS).
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
@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.
Ist die Firmware der Swisscom Internet-Box auf dem aktuellen Stand?
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:
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:
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
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:
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.
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.
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:
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
MTU-Test
Glasfaser-DHCP-Privatabo
http://www.letmecheck.it/mtu-test.php
Die maximale MTU-Größe beträgt: 1500
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…
