@hed wrote:

Swisscom does not throttle anything, but TV and VoIP have a higher priority (QoS) compared to the rest of the data traffic.

The IPerf(3) measurements show “black and white” that the UDP data traffic in the downstream direction is throttled to around 655 kbit/s. Independent of the current IPerf(3) measurements, other Swisscom fiber optic private customers have also noticed this UDP throttling (100KBytes/sec => around 1 to 2 MBit/s) with the Swisscom Internet box:

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Very-strong-UDP-throttling-in-the-network/td-p/397658)

QoS only comes into effect when the data packets accumulate in a network component. In the current case, this would be the case if the data traffic in the downstream direction is > 100 Mbit/s, which cannot be achieved with Swisscom TV alone. The IPerf(3) measurements were deliberately carried out with a UDP data stream of 95 instead of 100 Mbit/s so that no queue congestion could form in any network component and the QoS could distort the measurement.

For the IPerf(3) measurements, the fiber optic cable must be unloaded (idle). The measuring computer should be the only home network participant on the Internet box.

Show original language (German)

Hello @GrandDixence

“Independent of the current IPerf(3) measurements, other Swisscom fiber optic private customers have also noticed this UDP throttling (100KBytes/sec => around 1 to 2 Mbit/s) with the Swisscom Internet box.”

\=> Maybe this is the reason why I’m still waiting for a call/return from My Service. Unfortunately I’m not quite as flexible this week, I hope to be able to do more tests on Thursday and make a call to Swisscom.

“For the IPerf(3) measurements, the fiber optic cable must be unloaded (idle). The measuring computer should be the only home network participant on the Internet box.”

I will “create” this scenario again and then test it. Thanks again for the detailed information and help!

“Is the firmware of the Swisscom Internet-Box up to date?”

Yes, I also tested each with beta versions. I’ll check the versions on my Internet Box this evening and then add them here.~

Edit 6:39 p.m.:

My “Installed Firmware Version”: 07.50.41/07.50.35/1003

Show original language (German)

Hello @GrandDixence

I just tested it out on the train “for fun” with teathering and my laptop. Same result, after the first run the line is throttled to 655kbit/s.

If I omit the -u parameter I get much higher speeds. So apparently Swisscom simply generally means that UDP is extremely throttled.

Show original language (German)

IPerf(3) measurements over the mobile network with a Swisscom SIM card show high packet loss rates in the downstream direction with a UDP packet size of 8 kilobytes. With IPerf(3) the default setting of the UDP packet size is 8 kilobytes.

First, reduce the UDP packet size significantly below the MTU value using the IPerf parameter “-l” (Ethernet: 1500 bytes, PPPoE: < 1493 bytes):

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

leads to acceptable packet loss rates (< 1%). The reason for this behavior is probably IP fragmentation:

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

If IPv4 packets have to be fragmented by network components (the receiving side has a larger MTU value than the sending side), the fragmentation and the subsequent assembly/reassembly of the IPv4 packets leads to performance losses. Therefore, some IP routers/firewalls do not accept fragmented IPv4 packets for performance reasons and to protect against DoS attacks:

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

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

In IPv6, IP routers are not allowed to fragment IP packets. TCP transmissions adapt the IP packet size to the smallest MTU of the transmission path:

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

UDP has no mechanism for detecting the smallest MTU in the transmission path.

Why the MTU on the Swisscom fiber optic connection is not 1500 bytes is a mystery to me. Does Swisscom use PPP for fiber optic connections?

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

For UDP data transmission, the Internet connection via the television cable network (EuroDOCSIS) has an advantage. My IPerf(3) measurements on the EuroDOCSIS cable modem in downstream measurements with 65507 byte UDP packets show normal packet loss rates around 1%. UDP packets may have a maximum size of 65507 bytes:

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

Show original language (German)

Hello @akai

I’m sure you want to tell me something with your post. Unfortunately I don’t know what.

\=> Are you assuming that throttling UDP (regardless of the packet size) definitely has NO influence on my problems with XBOX Live when playing Fifa in Ultimate Team mode?

If so, that would be good to know (and possibly why) so that I don’t look in the wrong place.

Merci and greetings

Show original language (German)

Hello @GrandDixence

Once again, many! Thanks to! for your detailed answer with links. I hope that with all this information I can find a solution with Swisscom support.

As far as I remember, the XBOX One at MTU has the value 1480. Maybe something is really not harmonizing here.

I remember that for a while I had no problems playing online. Unfortunately, I don’t know exactly when this happened. Roughly speaking, about 1 month during the period from October to February, unfortunately I have no idea when exactly it was (at that time it was still via DSL)

I hope that I can find a solution with Swisscom, otherwise I now have a few things (UDP throttling and MTU) which I will definitely check in advance with the support of my new provider. I hope this isn’t a general fiber problem, but I can’t imagine it being.

(The worst case scenario turns out that none of this had any influence at all and that in the end Micorosoft and EA with their servers are the cause, but at the moment I still have “hope”).

Show original language (German)

It looks like Swisscom is using PPPoE for the fiber optic connection:

[http://documents.swisscom.com/product/1000260-Connectivity\_Geraete\_/Documents/ Specifications/Centro_Business_PPPoE_Passthrough-de.pdf](http://documents.swisscom.com/product/ 1000260-Connectivity_Geraete_/Documents/ Specifications/Centro_Business_PPPoE_Passthrough-de.pdf)

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

According to the IPerf(3) measurements, the use of PPPoE leads to massive packet losses with large UDP packets (> approx. 1400 bytes). The following offers a solution to the “big UDP packet problem”:

a) Use of a fiber optic connection from a third party without the need for a router

b) OR the implementation of a PPPoE-free fiber optic connection: removal of the Swisscom Internet box and the use of a media converter copper Ethernet <-> fiber optic Ethernet

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Very-strong-UDP-throttling-in-the-network/td-p/397658)

[https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glas Fiber-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171#M1 056](https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glasfibro-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171 #M1056)

I doubt that large UDP packets > 1400 bytes are used for the games and therefore no measure a) or b) is necessary. The only way to be certain here is to analyze the network traffic recordings with Wireshark:

https://www.wireshark.org/

If the IPerf(3) measurements with UDP packets < 1400 bytes in the downstream direction prove that the fiber optic connection is functioning properly (packet loss rate < 0.01% and jitter < 1 millisecond) AND the games do not use UDP packets > 1400 bytes, then this is the case The ball is back in the court of the network operator (Swisscom), their peering partners and the game server operators.

Show original language (German)

@GrandDixence

FTTH still has a VLAN on it. That’s why there should actually be 4 bytes left.

DHCP is used for private customers.

So theoretically the maximum MTU there is 1496

I have a PPPoE termination over FTTH and VLAN. I would have 1492. Effectively but only 1488 because of the VLAN.

That’s how it is with me.

But no one from Swisscom has ever confirmed this 😉 I just said that you should actually adapt the config sheets for firewalls accordingly.

It would be cool for someone to test the effective MTU on their FTTH private customer connection.

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

Show original language (German)

tiibor

I wanted you to just copy and paste and find out for yourself. That it is just a measurement error. My colleague above has already explained why -l x is so important in UDP.

Well I’m just with a small one. Bandwidth blessed. But I think with fine tuning of the values ​​-b and -l you will now reach the max. Unless there really is an L1 problem on site. But based on your description this can be ruled out.

Because the traceroute/MTR to easo.ea.com is also OK, i.e. no routing problem is visible. Can this definitely be ruled out?

Also that you didn’t write that everything with the box is slow. But rather just a game in particular. Indicates a problem with the game server itself! Due to the lack of hardware, I can’t say anything precise about it.

Now I would create another trouble ticket with all the new findings from the game provider and see if there is more to come this time. If you write again everything is ok. ask how you can check this yourself?

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

Show original language (German)

Then you have no.11q tagging on the ew Zürinet and DHCP as access technology, so 1500 is good for IPv4.

But I’m actually asking about FTTH Swisscom customers or one on the BBCS-F network.

There you have.11q tagging and the MTU can’t be 1500.

So just be aware of it when you get into problems. Not even related to this thread but in general.

Show original language (German)

@Tux0ne wrote:

@GrandDixence

FTTH still has a VLAN on it. That’s why there should actually be 4 bytes left.

Theoretically the maximum MTU there is 1496

The statement is not entirely correct: When using VLAN according to IEEE 802.1Q over Ethernet, the maximum amount of user data remains 1500 bytes and thus the MTU remains at 1500 bytes. VLAN according to IEEE 802.1Q over Ethernet has no influence on the MTU value. When using VLAN, the Ethernet frame simply becomes 4 bytes larger (1522 bytes instead of 1518 bytes):

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

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

Only when using “double tagging” does the MTU decrease to 1496 when using VLAN according to IEEE 802.1Q over 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](http://www.cisco.com/c/ en/us/support/docs/lan-switching/8021q/17056-741-4.html#frame2)

Show original language (German)

@GrandDixence

Yes, you’re right. I can’t transfer this to RES connections. I made a mistake in my thinking.

When I get the chance, I’ll take a look at why I have a maximum of 1488 in my setup (my KMU Office Dual Session WAN PPPoE passthrough).

The documentation simply doesn’t exist in this regard. You have to see for yourself where you stay 😉

Show original language (German)

Hi @akai

Thank you for your answer and explanation. Have you run it with these parameters (setup: Only PC directly on the router as the only device):

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.

Sometimes, however, I also had a strange behavior like this one (but it could also be in the server):

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.

Unfortunately, I have no idea what exactly it looks like with the packages and their size when playing online via XBOX One and Fifa Ultimate. Yesterday evening I tried again, and then I noticed that the game freezes in certain situations more than in others. Possibly these are situations in which more traffic comes, or larger packages, no idea.

I’ll see what the support says. Possibly there are even more possibilities to test. Also, my signal levels still seem strange. If all this does not help, I will test another provider in parallel. If it works without problems with this other provider, I can at least “show” Swisscom that it is your fault. If it doesn’t help, I give up. (I’ll have to check, maybe I can test a different provider from a neighbor via WLan in advance, WLAN is not ideal, but would be interesting)

Edit: Why is my browser’s spell checker not active in this forum? Haven’t had this problem anywhere else…

Show original language (Luxembourgish)

@Tux0ne

I tested MTU, via your link I get to 1472: i.e. 1500. Using the link from @XT I get to “The maximum MTU size for 178.199.89.xxx is: 1500”

But that may have already been resolved anyway.

@GrandDixence

“If the IPerf(3) measurements with UDP packets < 1400 bytes in the downstream direction prove that the fiber optic connection is functioning properly (packet loss rate < 0.01% and jitter < 1 millisecond)”

I think jitter is fine, but packet loss rate is not:

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.

“AND the games don’t use UDP packets > 1400 bytes, then the ball is back in the court of the network operator (Swisscom), their peering partners and the game server operators.”

Unfortunately I have no idea. But if I look at the behavior in the game, it’s not always bad. Is it possible that it only appears on moves where more information may flow?

See two videos (are links to OneDrive):

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

https://1drv.ms/v/s!AkNoK6Dl-AMqgRHPredIY2j4JBuA (clearly at second ~ 16 in this video)

You can see in these videos that the jerking is sometimes quite extreme. When gaming, this can best be described as input lag. It feels like everything is too sluggish, sometimes to the point of being “externally controlled”.

Show original language (German)

    tiibor

    tiibor schrieb:

    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.

    Ja, die Paketverlustrate ist für UDP-Pakete mit einer Nutdatengrösse von 512 Byte viel zu hoch.

    Zudem sind 24 UDP-Pakete in der falschen Reihenfolge empfangen worden (out-of-order), was ein Zeichen für eine überlastete Netzwerkkomponente ist.

    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.

    This post is in English

      Is the entire home network compatible with Gigabit Ethernet (1000 MBit/s)? Are all Ethernet cables in the home network labeled “Cat. 5e” or higher (e.g. “Cat. 6” or “Cat. 7”)? Are all network components in the home network (e.g. switch) Gigabit Ethernet compatible? Does Windows indicate the use of Gigabit Ethernet mode (1000 MBit/s) on the measurement PC?

      [https://www.swisscom.ch/de/privatkunden/hilfe/loesung/heimnetzwerk-zu-langsam.html](https://www.swisscom.ch/de/privatkunden/hilfe/loesung/heimnetzwerk-zu- slow.html)

      [https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-Computer/Ethernet-Problem/td-p/399781](https://community.swisscom.ch/t5/Diskussionen-%C3% BCber computer/Ethernet problem/td-p/399781)

      Show original language (German)