@hed a écrit :

Swisscom ne limite rien, mais la TV et la VoIP ont une priorité (QoS) plus élevée que le reste du trafic de données.

Les mesures IPerf(3) montrent « noir sur blanc » que le trafic de données UDP dans le sens descendant est limité à environ 655 kbit/s. Indépendamment des mesures IPerf(3) actuelles, d’autres clients privés Swisscom fibre optique ont également constaté ce throttling UDP (100 Ko/s => environ 1 à 2 MBit/s) avec la box Internet Swisscom :

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Limitation-UDP-très forte-dans-le-réseau/td-p/397658)

La QoS n’entre en vigueur que lorsque les paquets de données s’accumulent dans un composant réseau. Dans le cas actuel, cela serait le cas si le trafic de données dans le sens descendant est > 100 Mbit/s, ce qui ne peut pas être atteint avec Swisscom TV seul. Les mesures IPerf(3) ont été délibérément effectuées avec un flux de données UDP de 95 au lieu de 100 Mbit/s afin qu’aucune congestion de file d’attente ne puisse se former dans aucun composant du réseau et que la QoS ne puisse fausser la mesure.

Pour les mesures IPerf(3), le câble à fibre optique doit être déchargé (inactif). L’ordinateur de mesure doit être le seul participant du réseau domestique sur la box Internet.

Afficher la langue d’origine (Allemand)

Bonjour @GrandDixence

“Indépendamment des mesures IPerf(3) actuelles, d’autres clients privés Swisscom fibre optique ont également constaté ce throttling UDP (100 Ko/s => environ 1 à 2 Mbit/s) avec la box Internet Swisscom.”

\=> C’est peut-être la raison pour laquelle j’attends toujours un appel/retour de Mon Service. Malheureusement, je ne suis pas aussi flexible cette semaine, j’espère pouvoir faire plus de tests jeudi et appeler Swisscom.

“Pour les mesures IPerf(3), le câble à fibre optique doit être déchargé (inactif). L’ordinateur de mesure doit être le seul participant du réseau domestique sur la box Internet.”

Je vais “créer” à nouveau ce scénario puis le tester. Merci encore pour les informations détaillées et l’aide !

« Le micrologiciel du Swisscom Internet-Box est-il à jour ? »

Oui, j’ai également testé chacun avec des versions bêta. Je vérifierai les versions sur ma Box Internet ce soir puis je les ajouterai ici.~

Modifier 18h39 :

Ma “Version du firmware installé” : 07.50.41/07.50.35/1003

Afficher la langue d’origine (Allemand)

Bonjour @GrandDixence

Je viens de le tester dans le train « pour m’amuser » avec le teaking et mon ordinateur portable. Même résultat, après la première exécution, la ligne est limitée à 655 kbit/s.

Si j’omets le paramètre -u, j’obtiens des vitesses beaucoup plus élevées. Apparemment, Swisscom veut simplement dire que l’UDP est extrêmement limité.

Afficher la langue d’origine (Allemand)

Les mesures IPerf(3) sur le réseau mobile avec une carte SIM Swisscom montrent des taux de perte de paquets élevés dans le sens descendant avec une taille de paquet UDP de 8 kilo-octets. Avec IPerf(3), le paramètre par défaut de la taille du paquet UDP est de 8 kilo-octets.

Tout d’abord, réduisez la taille du paquet UDP considérablement en dessous de la valeur MTU à l’aide du paramètre IPerf « -l » (Ethernet : 1 500 octets, PPPoE : < 1 493 octets) :

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

conduit à des taux de perte de paquets acceptables (< 1 %). La raison de ce comportement est probablement la fragmentation IP :

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

Si les paquets IPv4 doivent être fragmentés par des composants du réseau (le côté réception a une valeur MTU plus grande que le côté envoi), la fragmentation et l’assemblage/réassemblage ultérieur des paquets IPv4 entraînent des pertes de performances. Par conséquent, certains routeurs/pare-feu IP n’acceptent pas les paquets IPv4 fragmentés pour des raisons de performances et pour se protéger contre les attaques DoS :

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

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

Dans IPv6, les routeurs IP ne sont pas autorisés à fragmenter les paquets IP. Les transmissions TCP adaptent la taille du paquet IP au plus petit MTU du chemin de transmission :

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

UDP ne dispose d’aucun mécanisme pour détecter la plus petite MTU sur le chemin de transmission.

Pourquoi le MTU sur la connexion fibre optique de Swisscom n’est pas de 1500 octets est pour moi un mystère. Swisscom utilise-t-elle le PPP pour les connexions par fibre optique ?

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

Pour la transmission de données UDP, la connexion Internet via le réseau de télévision par câble (EuroDOCSIS) présente un avantage. Mes mesures IPerf(3) sur le modem câble EuroDOCSIS dans les mesures en aval avec des paquets UDP de 65 507 octets montrent des taux de perte de paquets normaux d’environ 1 %. Les paquets UDP peuvent avoir une taille maximale de 65 507 octets :

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

Afficher la langue d’origine (Allemand)

Bonjour @akai

Je suis sûr que vous voulez me dire quelque chose avec votre message. Malheureusement, je ne sais pas quoi.

\=> Pensez-vous que la limitation d’UDP (quelle que soit la taille du paquet) n’a définitivement AUCUNE influence sur mes problèmes avec XBOX Live lorsque je joue à Fifa en mode Ultimate Team ?

Si c’est le cas, ce serait bon à savoir (et peut-être pourquoi) pour ne pas chercher au mauvais endroit.

Merci et salutations

Afficher la langue d’origine (Allemand)

Bonjour @GrandDixence

Encore une fois, nombreux ! Grâce à! pour votre réponse détaillée avec des liens. J’espère qu’avec toutes ces informations, je pourrai trouver une solution avec le support Swisscom.

Pour autant que je me souvienne, la XBOX One chez MTU a la valeur 1480. Peut-être que quelque chose ne s’harmonise vraiment pas ici.

Je me souviens que pendant un moment, je n’ai eu aucun problème pour jouer en ligne. Malheureusement, je ne sais pas exactement quand cela s’est produit. En gros, environ 1 mois sur la période d’octobre à février, malheureusement je ne sais pas exactement quand c’était (à cette époque c’était encore via DSL)

J’espère pouvoir trouver une solution avec Swisscom, sinon j’ai maintenant quelques points (limitation UDP et MTU) que je vérifierai certainement à l’avance avec le support de mon nouveau fournisseur. J’espère que ce n’est pas un problème général de fibre, mais je ne peux pas imaginer que ce soit le cas.

(Dans le pire des cas, il s’avère que rien de tout cela n’a eu d’influence et qu’en fin de compte, Microsoft et EA avec leurs serveurs en sont la cause, mais pour le moment, j’ai encore « de l’espoir »).

Afficher la langue d’origine (Allemand)

Il semble que Swisscom utilise PPPoE pour la connexion par fibre optique :

[http://documents.swisscom.com/product/1000260-Connectivity\_Geraete\_/Documents/Spécifications/Centro\_Business\_PPPoE\_Passthrough-de.pdf](http://documents.swisscom.com/product/ 1000260-Connectivity_Geraete_/Documents/Spécifications/Centro_Business_PPPoE_Passthrough-de.pdf)

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

Selon les mesures IPerf(3), l’utilisation de PPPoE entraîne des pertes massives de paquets pour les gros paquets UDP (> environ 1400 octets). Ce qui suit propose une solution au « gros problème des paquets UDP » :

a) Utilisation d’une connexion fibre optique d’un tiers sans avoir besoin d’un routeur

b) OU la mise en place d’une connexion fibre optique sans PPPoE : suppression de la box Internet Swisscom et utilisation d’un convertisseur de média Ethernet cuivre <-> Ethernet fibre optique

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Limitation-UDP-très forte-dans-le-réseau/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)

Je doute que de gros paquets UDP > 1 400 octets soient utilisés pour les jeux et donc aucune mesure a) ou b) n’est nécessaire. La seule façon d’en être sûr est d’analyser les enregistrements du trafic réseau avec Wireshark :

https://www.wireshark.org/

Si les mesures IPerf(3) avec des paquets UDP < 1400 octets dans le sens aval prouvent que la connexion fibre optique fonctionne correctement (taux de perte de paquets < 0,01% et gigue < 1 milliseconde) ET les jeux n’utilisent pas de paquets UDP > 1400 octets , alors c’est le cas. La balle est de nouveau dans le camp de l’opérateur de réseau (Swisscom), de ses partenaires de peering et des opérateurs de serveurs de jeux.

Afficher la langue d’origine (Allemand)

@GrandDixence

FTTH dispose toujours d’un VLAN. C’est pourquoi il devrait rester 4 octets.

DHCP est utilisé pour les clients privés.

Donc théoriquement, le MTU maximum est de 1496

J’ai une terminaison PPPoE sur FTTH et VLAN. J’en aurais 1492. Effectivement mais seulement 1488 à cause du VLAN.

C’est comme ça avec moi.

Mais personne chez Swisscom ne l’a jamais confirmé 😉 Je viens de dire qu’il fallait effectivement adapter les feuilles de configuration des pare-feu en conséquence.

Ce serait cool pour quelqu’un de tester le MTU efficace sur sa connexion client privée FTTH.

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

Afficher la langue d’origine (Allemand)

tiibor

Je voulais que vous copiez et collez et que vous découvriez par vous-même. Que c’est juste une erreur de mesure. Mon collègue ci-dessus a déjà expliqué pourquoi -l x est si important dans UDP.

Eh bien, je suis juste avec un petit. Bande passante bénie. Mais je pense qu’avec un réglage fin des valeurs -b et -l vous atteindrez désormais le maximum. A moins qu’il y ait vraiment un problème de L1 sur place. Mais d’après votre description, cela peut être exclu.

Parce que le traceroute/MTR vers easo.ea.com est également OK, c’est-à-dire qu’aucun problème de routage n’est visible. Cela peut-il être définitivement exclu ?

Aussi que vous n’avez pas écrit que tout avec la boîte est lent. Mais plutôt juste un jeu en particulier. Indique un problème avec le serveur de jeu lui-même ! En raison du manque de matériel, je ne peux rien dire de précis à ce sujet.

Maintenant, je créerais un autre ticket d’incident avec toutes les nouvelles découvertes du fournisseur de jeu et verrais s’il y a plus à venir cette fois. Si vous écrivez à nouveau, tout va bien. demandez comment vous pouvez vérifier cela vous-même ?

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

[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-1,01 s 192 Ko 1,56 Mbits/s 10 698 ms 252/276 (91 %)
[ 4] 1,01-2,01 s 80,0 Ko 655 Kbits/s 5 897 ms 296/306 (97 %)
[ 4] 2,01-3,01 s 80,0 Ko 655 Kbits/s 3 433 ms 295/305 (97 %)
[ 4] 3,01-4,01 s 80,0 Ko 654 Kbits/s 2 143 ms 295/305 (97 %)
[ 4] 4,01-5,01 s 80,0 Ko 656 Kbits/s 1 435 ms 295/305 (97 %)
[ 4] 5,01-6,01 s 80,0 Ko 655 Kbits/s 0,986 ms 295/305 (97 %)
[ 4] 6,01-7,01 s 80,0 Ko 655 Kbits/s 0,741 ms 295/305 (97 %)
[ 4] 7,01-8,01 s 80,0 Ko 655 Kbits/s 0,810 ms 296/306 (97 %)
[ 4] 8,01-9,01 s 80,0 Ko 655 Kbits/s 0,855 ms 295/305 (97 %)
[ 4] 9,01-10,01 s 80,0 Ko 655 Kbits/s 0,569 ms 295/305 (97 %)
- - - - - - - - - - - - - - - - - - - - - - - -
[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-10,01 s 23,8 Mo 20,0 Mbits/s 0,569 ms 2909/3023 (96 %)
[ 4] Envoyé 3023 datagrammes

iperf Terminé.

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

[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-1,00 s 1,31 Mo 11,0 Mbits/s 0,848 ms 506/1477 (34 %)
[ 4] 1,00-2,00 s 1,24 Mo 10,4 Mbits/s 0,795 ms 895/1811 (49 %)
[ 4] 2,00-3,00 s 1,24 Mo 10,4 Mbits/s 6 828 ms 903/1 822 (50 %)
[ 4] 3,00-4,00 s 1,25 Mo 10,4 Mbits/s 0,730 ms 829/1749 (47 %)
[ 4] 4,00-5,00 s 1,25 Mo 10,5 Mbits/s 0,829 ms 789/1709 (46 %)
[ 4] 5,00-6,00 s 1,25 Mo 10,5 Mbits/s 0,831 ms 837/1757 (48 %)
[ 4] 6,00-7,00 s 1,25 Mo 10,4 Mbits/s 0,764 ms 863/1783 (48 %)
[ 4] 7,00-8,00 s 1,25 Mo 10,5 Mbits/s 0,707 ms 878/1798 (49 %)
[ 4] 8,00-9,00 s 1,25 Mo 10,5 Mbits/s 0,783 ms 806/1726 (47 %)
[ 4] 9,00-10,00 s 1,25 Mo 10,4 Mbits/s 0,772 ms 833/1753 (48 %)
- - - - - - - - - - - - - - - - - - - - - - - -
[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-10,00 s 23,8 Mo 20,0 Mbits/s 1 481 ms 8259/17606 (47 %)
[ 4] Envoyé 17606 datagrammes

% de perte de l’hôte Snt Dernière moy. Meilleur premier StDev
….
14. easo.ea.com 0,0% 310 111,7 111,7 109,9 149,5 2,8

Afficher la langue d’origine (Allemand)

Ensuite, vous avez le marquage n°11q sur le nouveau Zürinet et DHCP comme technologie d’accès, donc 1500 est bon pour IPv4.

Mais je pose en fait des questions sur les clients FTTH Swisscom ou sur le réseau BBCS-F.

Là, vous avez le balisage .11q et le MTU ne peut pas être de 1 500.

Alors soyez-en conscient lorsque vous rencontrez des problèmes. Même pas lié à ce fil mais en général.

Afficher la langue d’origine (Allemand)

@Tux0ne a écrit :

@GrandDixence

FTTH dispose toujours d’un VLAN. C’est pourquoi il devrait rester 4 octets.

Théoriquement le MTU maximum y est de 1496

L’affirmation n’est pas tout à fait correcte : lors de l’utilisation d’un VLAN selon IEEE 802.1Q sur Ethernet, la quantité maximale de données utilisateur reste de 1 500 octets et la MTU reste donc de 1 500 octets. Le VLAN selon IEEE 802.1Q sur Ethernet n’a aucune influence sur la valeur MTU. Lors de l’utilisation d’un VLAN, la trame Ethernet devient simplement plus grande de 4 octets (1 522 octets au lieu de 1 518 octets) :

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

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

Ce n’est qu’en utilisant le « double marquage » que le MTU diminue à 1 496 lors de l’utilisation d’un VLAN selon IEEE 802.1Q sur 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)

Afficher la langue d’origine (Allemand)

@GrandDixence

Oui, tu as raison. Je ne peux pas transférer cela vers les connexions RES. J’ai fait une erreur dans ma réflexion.

Lorsque j’en aurai l’occasion, j’examinerai pourquoi j’ai un maximum de 1488 dans ma configuration (mon relais KMU Office Dual Session WAN PPPoE).

La documentation n’existe tout simplement pas à cet égard. Vous devez voir par vous-même où vous séjournez 😉

Afficher la langue d’origine (Allemand)

Salut @akai

Merci pour votre réponse et explication. L’avez-vous exécuté avec ces paramètres (configuration : uniquement PC directement sur le routeur comme seul appareil) :

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Connexion à l’hébergeur debit.k-net.fr, port 5201
Mode inversé, l’hôte distant debit.k-net.fr envoie
[ 4] port local 192.168.1.107 57470 connecté au port 178.250.209.22 5201
[ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-1,00 s 9,00 Mo 75,5 Mbits/s 0,012 ms 7966/26392 (30 %)
[ 4] 1,00-2,00 s 8,16 Mo 68,5 Mbits/s 0,011 ms 6584/23303 (28 %)
[ 4] 2,00-3,00 s 9,29 Mo 78,0 Mbits/s 0,009 ms 4195/23226 (18 %)
[ 4] 3,00-4,00 s 9,23 Mo 77,4 Mbits/s 0,009 ms 4247/23149 (18 %)
[ 4] 4,00-5,00 s 8,82 Mo 74,0 Mbits/s 0,009 ms 5382/23451 (23 %)
[ 4] 5,00-6,00 s 9,71 Mo 81,4 Mbits/s 0,005 ms 3314/23197 (14 %)
[ 4] 6,00-7,00 s 9,35 Mo 78,4 Mbits/s 0,008 ms 3859/23006 (17 %)
[ 4] 7,00-8,00 s 9,53 Mo 79,9 Mbits/s 0,009 ms 3707/23221 (16 %)
[ 4] 8,00-9,00 s 9,25 Mo 77,6 Mbits/s 0,008 ms 4206/23160 (18 %)
[ 4] 9,00-10,00 s 9,65 Mo 80,9 Mbits/s 0,008 ms 3523/23277 (15 %)
- - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-10,00 s 115 Mo 96,7 Mbits/s 0,005 ms 46983/236021 (20 %)
[ 4] Envoyé 236021 datagrammes

iperf Terminé.

Parfois, cependant, j’avais aussi un comportement étrange comme celui-ci (mais cela pouvait aussi provenir du serveur) :

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Connexion à l’hébergeur debit.k-net.fr, port 5201
Mode inversé, l’hôte distant debit.k-net.fr envoie
[ 4] port local 192.168.1.107 59573 connecté au port 178.250.209.22 5201
iperf3 : HORS ORDRE - paquet entrant = 50 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 51 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 52 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 53 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 54 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 55 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 56 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 57 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 58 et paquet reçu = 0 ET SP = 66
iperf3 : HORS ORDRE - paquet entrant = 59 et paquet reçu = 0 ET SP = 66
[ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-1,01 s 6,43 Mo 53,2 Mbits/s 0,011 ms 12 675/25 830 (49 %)
[ 4] 1,01-2,00 s 5,10 Mo 43,4 Mbits/s 0,019 ms 12430/22881 (54 %)
[ 4] 2,00-3,00 s 5,09 Mo 42,5 Mbits/s 0,012 ms 11220/21650 (52 %)
[ 4] 3,00-4,00 s 6,48 Mo 54,6 Mbits/s 0,017 ms 11783/25056 (47 %)
[ 4] 4,00-5,01 s 5,81 Mo 48,2 Mbits/s 0,010 ms 11317/23212 (49 %)
[ 4] 5,01-6,01 s 4,56 Mo 38,3 Mbits/s 0,014 ms 13383/22728 (59 %)
[ 4] 6,01-7,01 s 5,16 Mo 43,3 Mbits/s 0,135 ms 13060/23630 (55 %)
[ 4] 7,01-8,00 s 6,07 Mo 51,2 Mbits/s 0,290 ms 10 585/23 018 (46 %)
[ 4] 8,00-9,00 s 4,36 Mo 36,7 Mbits/s 0,016 ms 13178/22105 (60 %)
[ 4] 9,00-10,00 s 6,34 Mo 53,0 Mbits/s 0,034 ms 11006/23995 (46 %)
- - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-10,00 s 115 Mo 96,1 Mbits/s 0,034 ms 120637/234105 (52 %)
[ 4] Envoyé 234 105 datagrammes
[SUM] 0,0-10,0 s 10 datagrammes reçus dans le désordre

iperf Terminé.

Malheureusement, je n’ai aucune idée de ce à quoi cela ressemble exactement avec les packages et leur taille lorsque l’on joue en ligne via XBOX One et Fifa Ultimate. Hier soir, j’ai réessayé, puis j’ai remarqué que le jeu se fige plus dans certaines situations que dans d’autres. Il s’agit peut-être de situations dans lesquelles davantage de trafic arrive, ou des colis plus importants, aucune idée.

Je vais voir ce que dit le support. Il existe peut-être encore plus de possibilités à tester. De plus, mes niveaux de signal semblent toujours étranges. Si tout cela n’aide pas, je testerai en parallèle un autre prestataire. Si cela fonctionne sans problème avec cet autre fournisseur, je peux au moins “montrer” à Swisscom que c’est de votre faute. Si ça n’aide pas, j’abandonne. (Je vais devoir vérifier, je peux peut-être tester à l’avance un autre fournisseur d’un voisin via WLan, le WLAN n’est pas idéal, mais serait intéressant)

Edit : Pourquoi le correcteur orthographique de mon navigateur n’est-il pas actif sur ce forum ? Je n’ai rencontré ce problème nulle part ailleurs…

Afficher la langue d’origine (Luxembourgeois)

@Tux0ne

J’ai testé MTU, via votre lien j’arrive à 1472 : soit 1500. En utilisant le lien de @XT j’arrive à “La taille maximale de MTU pour 178.199.89.xxx est : 1500”

Mais de toute façon, cela a peut-être déjà été résolu.

@GrandDixence

“Si les mesures IPerf(3) avec des paquets UDP < 1400 octets dans le sens aval prouvent que la connexion fibre optique fonctionne correctement (taux de perte de paquets < 0,01 % et gigue < 1 milliseconde)”

Je pense que la gigue est bonne, mais le taux de perte de paquets ne l’est pas :

iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
Connexion à l’hébergeur debit.k-net.fr, port 5201
Mode inversé, l’hôte distant debit.k-net.fr envoie
[ 4] port local 192.168.1.107 60488 connecté au port 178.250.209.22 5201
iperf3 : HORS ORDRE - paquet entrant = 58 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 59 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 60 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 61 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 62 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 63 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 64 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 65 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 66 et paquet reçu = 0 ET SP = 109
iperf3 : HORS ORDRE - paquet entrant = 67 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 68 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 69 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 70 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 71 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 72 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 73 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 74 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 75 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 76 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 77 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 78 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 79 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 80 et paquet reçu = 0 ET SP = 127
iperf3 : HORS ORDRE - paquet entrant = 81 et paquet reçu = 0 ET SP = 127
[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-1,00 s 8,46 Mo 71,0 Mbits/s 0,034 ms 8660/25971 (33 %)
[ 4] 1,00-2,00 s 9,35 Mo 78,5 Mbits/s 0,009 ms 4052/23208 (17 %)
[ 4] 2,00-3,00 s 10,1 Mo 84,5 Mbits/s 0,010 ms 2544/23179 (11 %)
[ 4] 3,00-4,00 s 9,69 Mo 81,2 Mbits/s 0,015 ms 3218/23063 (14 %)
[ 4] 4,00-5,00 s 9,84 Mo 82,5 Mbits/s 0,012 ms 3136/23288 (13 %)
[ 4] 5,00-6,00 s 9,08 Mo 76,2 Mbits/s 0,021 ms 4569/23171 (20 %)
[ 4] 6,00-7,00 s 9,78 Mo 82,0 Mbits/s 0,009 ms 3125/23146 (14 %)
[ 4] 7,00-8,00 s 9,69 Mo 81,2 Mbits/s 0,010 ms 3688/23527 (16 %)
[ 4] 8,00-9,00 s 9,44 Mo 79,2 Mbits/s 0,010 ms 3598/22923 (16 %)
[ 4] 9,00-10,00 s 9,52 Mo 79,9 Mbits/s 0,009 ms 3748/23244 (16 %)
- - - - - - - - - - - - - - - - - - - - - - - -
[ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
[ 4] 0,00-10,00 s 115 Mo 96,4 Mbits/s 0,005 ms 40338/235379 (17 %)
[ 4] Envoyé 235379 datagrammes
[SUM] 0,0-10,0 s 24 datagrammes reçus dans le désordre

iperf Terminé.

“ET les jeux n’utilisent pas de paquets UDP > 1400 octets, alors la balle est de nouveau dans le camp de l’opérateur de réseau (Swisscom), de ses partenaires de peering et des opérateurs de serveurs de jeux.”

Malheureusement, je n’en ai aucune idée. Mais si je regarde le comportement dans le jeu, ce n’est pas toujours mauvais. Est-il possible qu’il n’apparaisse que sur les mouvements où davantage d’informations peuvent circuler ?

Voir deux vidéos (sont des liens vers OneDrive) :

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

https://1drv.ms/v/s!AkNoK6Dl-AMqgRHPredIY2j4JBuA (clairement à la seconde ~ 16 dans cette vidéo)

Vous pouvez voir dans ces vidéos que les secousses sont parfois assez extrêmes. Lorsque vous jouez, cela peut être décrit comme un décalage d’entrée. On a l’impression que tout est trop lent, parfois au point d’être « contrôlé de l’extérieur ».

Afficher la langue d’origine (Allemand)

    tiibor

    tiibor schrieb:

    Je pense que Jitter est dans Ordnung, Paketverlustrate charnièregen pas :

    iperf3 -u -R -c debit.k-net.fr -b 95M -l 512
    Connexion à l’hébergeur debit.k-net.fr, port 5201
    Mode inversé, l’hôte distant debit.k-net.fr envoie
    [ 4] port local 192.168.1.107 60488 connecté au port 178.250.209.22 5201
    iperf3 : HORS ORDRE - paquet entrant = 58 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 59 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 60 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 61 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 62 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 63 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 64 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 65 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 66 et paquet reçu = 0 ET SP = 109
    iperf3 : HORS ORDRE - paquet entrant = 67 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 68 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 69 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 70 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 71 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 72 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 73 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 74 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 75 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 76 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 77 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 78 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 79 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 80 et paquet reçu = 0 ET SP = 127
    iperf3 : HORS ORDRE - paquet entrant = 81 et paquet reçu = 0 ET SP = 127
    [ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
    [ 4] 0,00-1,00 s 8,46 Mo 71,0 Mbits/s 0,034 ms 8660/25971 (33 %)
    [ 4] 1,00-2,00 s 9,35 Mo 78,5 Mbits/s 0,009 ms 4052/23208 (17 %)
    [ 4] 2,00-3,00 s 10,1 Mo 84,5 Mbits/s 0,010 ms 2544/23179 (11 %)
    [ 4] 3,00-4,00 s 9,69 Mo 81,2 Mbits/s 0,015 ms 3218/23063 (14 %)
    [ 4] 4,00-5,00 s 9,84 Mo 82,5 Mbits/s 0,012 ms 3136/23288 (13 %)
    [ 4] 5,00-6,00 s 9,08 Mo 76,2 Mbits/s 0,021 ms 4569/23171 (20 %)
    [ 4] 6,00-7,00 s 9,78 Mo 82,0 Mbits/s 0,009 ms 3125/23146 (14 %)
    [ 4] 7,00-8,00 s 9,69 Mo 81,2 Mbits/s 0,010 ms 3688/23527 (16 %)
    [ 4] 8,00-9,00 s 9,44 Mo 79,2 Mbits/s 0,010 ms 3598/22923 (16 %)
    [ 4] 9,00-10,00 s 9,52 Mo 79,9 Mbits/s 0,009 ms 3748/23244 (16 %)
    - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
    [ 4] 0,00-10,00 s 115 Mo 96,4 Mbits/s 0,005 ms 40338/235379 (17 %)
    [ 4] Envoyé 235379 datagrammes
    [SUM] 0,0-10,0 s 24 datagrammes reçus dans le désordre

    iperf Terminé.

    Oui, le paquet est utilisé pour le paquet UDP avec une taille de noix de 512 octets pour vous. Zudem sind 24 UDP-Pakete in der falschen Reihenfolge empfangen worden (dans le désordre), était un Zeichen pour un überlastete Netzwerkkomponente ist. Comme déjà mentionné, Wireshark peut être utilisé pour déterminer la taille du paquet UDP utilisé par le jeu de manière relativement rapide et simple :

    Wireshark_UDP_paketgroesse.png

    Voici un exemple de ce à quoi devrait ressembler la mesure IPerf3 avec des paquets UDP dans le sens descendant (PC directement vers le modem câble EuroDOCSIS) :

    Mesure UDP du aval/téléchargement (100 Mbit/s)

    iperf3 -u -R -c débit.k-net.fr -b 100M

    Connexion à l’hébergeur debit.k-net.fr, port 5201
    Mode inversé, l’hôte distant debit.k-net.fr envoie
    [ 4] port local 77.57.166.140 40131 connecté au port 178.250.209.22 5201
    [ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
    [ 4] 0,00-1,00 s 11,2 Mo 94,2 Mbits/s 0,719 ms 0/1437 (0 %)
    [ 4] 1,00-2,00 s 11,9 Mo 100 Mbits/s 0,703 ms 0/1526 (0 %)
    [ 4] 2,00-3,00 s 11,9 Mo 100 Mbits/s 0,688 ms 0/1527 (0 %)
    [ 4] 3,00-4,00 s 11,9 Mo 99,9 Mbits/s 0,704 ms 0/1524 (0 %)
    [ 4] 4,00-5,00 s 11,9 Mo 100 Mbits/s 0,704 ms 0/1527 (0 %)
    [ 4] 5,00-6,00 s 11,9 Mo 100 Mbits/s 0,712 ms 0/1526 (0 %)
    [ 4] 6,00-7,00 s 11,9 Mo 100 Mbits/s 0,670 ms 0/1526 (0 %)
    [ 4] 7,00-8,00 s 11,9 Mo 99,9 Mbits/s 0,699 ms 0/1525 (0 %)
    [ 4] 8,00-9,00 s 11,9 Mo 100 Mbits/s 0,709 ms 0/1527 (0 %)
    [ 4] 9,00-10,00 s 11,9 Mo 100 Mbits/s 0,707 ms 0/1526 (0 %)

    [ID] Intervalle de transfert de bande passante Gigue perdue/Total des datagrammes
    [ 4] 0,00-10,00 s 119 Mo 100 Mbits/s 0,613 ms 0/15262 (0 %)
    [ 4] Envoyé 15 262 datagrammes

    iperf Terminé.

    Afficher la langue d’origine (Anglais)

      L’ensemble du réseau domestique est-il compatible avec Gigabit Ethernet (1000 Mbit/s) ? Tous les câbles Ethernet du réseau domestique sont-ils étiquetés « Cat. 5e » ou supérieur (par exemple « Cat. 6 » ou « Cat. 7 ») ? Tous les composants réseau du réseau domestique (par exemple le commutateur) sont-ils compatibles Gigabit Ethernet ? Windows indique-t-il l’utilisation du mode Gigabit Ethernet (1000 Mbit/s) sur le PC de mesure ?

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

      [https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-Computer/Ethernet-Problem/td-p/399781](https://community.swisscom.ch/t5/Diskussionen-%C3% Ordinateur BCber/Problème Ethernet/td-p/399781)

      Afficher la langue d’origine (Allemand)