La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: saM_31 le 14 octobre 2016 à 08:29:28
-
Bonjour à tous,
Je viens d'effectuer ma migration de l'ADSL Free vers FTTH (Aix-en-Provence, en ZMD). J'ai effectué des tests de débit et j'étais très satisfait (900/300Mbs) ! Même si j'ai vu de meilleurs pings ailleurs.
(https://s21.postimg.org/3kfnf2vur/avant.png) (https://postimg.org/image/3kfnf2vur/)
En essayant de mettre à jour mes redirections de port j'ai rencontré des soucis, et je me suis rendu compte que j'avais une IP partagée, et que je disposais du dernier quart des ports (45000-65000, quelque chose comme ça) (en fait les soucis venaient peut-être aussi du fait que mes modifs n'étaient pas prises en compte dans l'interface de gestion, qui ne semble pas synchronisée avec les configurations dans Freebox OS...). Après avoir lu différents forums, j'ai demandé une IP individuelle (IPv4 full-stack), option qui est plutôt vue d'un bon œil d'après ce que j'ai pu lire. Or je me suis rendu compte après ça que ma vitesse d'upload avait considérablement chuté (15/20Mbs), et ça ne s'est pas amélioré dans les jours suivants. Quand je fais des transferts depuis l'extérieur via le ftp Free je dépasse pas les 200 ko/s! De plus ma nouvelle IP ne semble plus géolocalisable, simplement "France" (d'où le serveur déplacé à Paris pour les tests de débit).
(https://s21.postimg.org/ofxccl2o3/après.png) (https://postimg.org/image/ofxccl2o3/)
J'ai activé l'IPv6 mais ça n'a rien changé.
Est-ce que des gens ici comprennent ce qui s'est passé? Si c'est normal? S'il est possible d'y remédier? Le principal intérêt de la fibre est pour moi est d'avoir une plus grande vitesse d'upload, notamment pour accéder à mes données depuis l'extérieur.
Merci.
-
Bonjour,
Ça semble effectivement anormal mais il faudrait tester sur le même serveur pour être sûr.
Que te dit https://testdebit.info ?
-
+1 il faut comparer sur le même serveur (ré-utilise le serveur de Nice)
Sur ce serveur le test se fait en IPv6 par défault.
Un upload aussi faible c'est vraiment étonnant.
Serait-il possible de tester en IPv4 vs IPv6 ?
Par exemple avec iperf3, voici les commandes pour tester l'upload :
iperf3 -c bouygues.testdebit.info -4 en IPv4
iperf3 -c bouygues.testdebit.info -6 en IPv6
iperf3 se télécharge sur https://iperf.fr/fr/iperf-download.php
-
Il semble que ça ce soit légèrement amélioré, ou alors ça dépend des jours et des heures de la journée... (mais c'est pas encore ça)
Le speed test avec le serveur de Nice:
(https://s9.postimg.org/itdeagdl7/speedtestnice.png) (https://postimg.org/image/itdeagdl7/)
Le test avec testdebit.info
(https://s9.postimg.org/kmgayryrv/73929611_YEdx1DFM.png) (https://postimg.org/image/kmgayryrv/)
Je ne suis fais un expert mais j'ai utilisé les commandes suggérées avec iperf3 (invite de commandes Windows - je suis sous Windows10). J'avoue que je ne comprends pas grand chose aux valeurs affichées mais en IPv4 je suis à environ 3.5Mbits/sec (sender et receiver) et en IPv6 à 1.6Mbits/sec.
En IPv4:
(https://s22.postimg.org/sdbtj8l6l/iperf3_4.png) (https://postimg.org/image/sdbtj8l6l/)
En IPv6
(https://s22.postimg.org/virtvpef1/iperf3_6.png) (https://postimg.org/image/virtvpef1/)
Merci de votre aide en tout cas.
-
Les résultats donnés par iPerf sont très mauvais. Il y a quelque chose de pas normal là.
-
Cela ressemble à de grosses pertes de paquets, qui sont compensés par les connexions multiples de nPerf / SpeedTest.
Pour diagnostique ce type de problème, il faut faire avec le même outil un test sur une connexion TCP et sur plusieurs.
Voici le test pour générer plusieurs 10 TCP en //. Il faut regarder la ligne [SUM] qui somme les 10 connexions TCP.
iperf3 -c bouygues.testdebit.info -P 10 -4 en IPv4
iperf3 -c bouygues.testdebit.info -P 10 -6 en IPv6
Serait-il possible en + de refaire le test précédent sur 1 connexion TCP ?
Si on a 10 x plus de débit sur 10 connexions, c'est un problème type perte de paquets ou déséquencement qui empêche à TCP de faire monter le débit.
Si on a le même débit catastrophique entre 1 et 10 connexion TCP, il faut s'orienter sur une limitation du protocole par le réseau.
-
Si vraiment on a de grosses pertes de paquets ça ne timeout pas ?
-
Non, il est possible de communiquer avec 80% de pertes de paquets.
C'est la magie de TCP. Par contre le débit ralenti fortement dés qu'il y a des pertes récurrentes.
-
Ok.
Donc avec iperf3 -c bouygues.testdebit.info -p 5202 -P 10 -4 (j'ai dû spécifier le port parce que ça me faisait "connection refused", alors que ça marchait très bien 2min avant...?) j'obtiens
[SUM] 0.00-10.01 sec 10.6 MBytes 8.91 Mbits/sec sender
[SUM] 0.00-10.01 sec 8.70 MBytes 7.30 Mbits/sec receiver
Avec iperf3 -c bouygues.testdebit.info -p 5202 -P 10 -6:
[SUM] 0.00-10.01 sec 10.2 MBytes 8.59 Mbits/sec sender
[SUM] 0.00-10.01 sec 8.41 MBytes 7.05 Mbits/sec receiver
Avec iperf3 -c bouygues.testdebit.info -p 5202 -P 1 -4:
[ 4] 0.00-10.01 sec 1.00 MBytes 838 Kbits/sec sender
[ 4] 0.00-10.01 sec 884 KBytes 723 Kbits/sec receiver
Avec iperf3 -c bouygues.testdebit.info -p 5202 -P 1 -6:
[ 4] 0.00-10.02 sec 1.00 MBytes 838 Kbits/sec sender
[ 4] 0.00-10.02 sec 795 KBytes 650 Kbits/sec receiver
Donc ça ressemble bien à un débit x10 quand il y a plus de connexions, c'est ça? (même si je ne sais pas ce que ça signifie par rapport à ma ligne...).
Pour info j'avais fait un pingtest.net (après avoir dû installer un Firefox 32bits pour faire marcher java) et j'avais "0 packet loss"...
-
Merci pour ces tests instructifs :
- IPv4 / IPv6 ne change rien
- les connexions TCP sont bridées à 800 Kb/s.
=> avec 10 connexions TCP en // on a 8 Mb/s
=> avec 100 connexions TCP en // on devrait avoir 80 Mb/s
Il me faudrait une capture wireshark pour comprendre pourquoi le débit TCP ne monte pas.
Il faut simplement démarrer la capture, faire un iperf3 (IPv4 ou IPv6 peu importe) sur une connexion TCP et arrêter la capture, puis enregistrer.
J'ai fais un tutoriel pour Wireshark, mais il commence à dater => Réaliser une capture Wireshark pas à pas (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
Autre idée, faire un iperf3 en UDP, sur le servuer Online : ping.online.net
par exemple : iperf3 -c ping.online.net -u -B 100m pour envoyer des paquets à un débit de 100 Mb/s (il te diras si il y a des paquets perdus)
-
J'ai eu pas mal de soucis à faire tourner Wireshark... En fait surtout l'exécutable "Wireshark Legacy" (Wireshark-gtk.exe) qui ressemble plus à l'interface du tuto. Il plante systématiquement ("... s'est arrêté') dès que je stoppe l'enregistrement. J'ai quand même pu réaliser un enregistrement avec la version standard (Wireshark.exe) sans toucher à aucun paramètre. Il s'agit d'un iperf3 -c bouygues.testdebit.info -p 5202 -6, dont les résultats donnaient
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 1.75 MBytes 1.47 Mbits/sec sender
[ 4] 0.00-10.00 sec 1.58 MBytes 1.32 Mbits/sec receiver
Je suis bien incapable de décrypter le rapport obtenu (en pj), j'espère qu'il n'y trop de déchets (j'avais des onglets Firefox ouverts, je ne sais pas si ça joue...).
Sinon, pour le test en UDP, j'ai aussi du mal à le faire tourner, "unable to connect to server" dès qu'il y a l'argument -B 100m (ou même -B 1m).
En tout cas avec simplement iperf3 -c ping.online.net -u j'obtiens des choses du genre
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.32 MBytes 1.11 Mbits/sec 0.320 ms 71/166 (43%)
[ 4] Sent 166 datagrams
Donc de la perte...
Je précise que je fais tout ça sous Windows10, dont je viens de voir qu'un paramètre "auto-tuning" devait peut-être être modifié (http://www.papergeek.fr/windows-10-bride-votre-connexion-internet-voici-comment-len-empecher-6333 (http://www.papergeek.fr/windows-10-bride-votre-connexion-internet-voici-comment-len-empecher-6333)).
Merci beaucoup en tout cas de m'aider à comprendre le problème !
-
Pour faire un retour sur l'évolution de la situation... Après un peu plus d'un mois, mon débit d'upload s'est brusquement amélioré! Sans que je modifie quoi que ce soit. Sur les SpeedTests, c'est assez variable, mais je tourne généralement à 800/200Mb/s (DL/UL) maintenant.
Avec iperf j'obtiens:
iperf3 -c bouygues.testdebit.info -P 10 -6
[SUM] 0.00-10.00 sec 104 MBytes 86.9 Mbits/sec sender
[SUM] 0.00-10.00 sec 102 MBytes 85.6 Mbits/sec receiver
ou
iperf3 -c bouygues.testdebit.info -P 1 -6
[ 4] 0.00-10.00 sec 12.8 MBytes 10.7 Mbits/sec sender
[ 4] 0.00-10.00 sec 12.6 MBytes 10.6 Mbits/sec receiver
Mon IP reste quand même difficilement géolocalisable (région parisienne alors que je suis plus proche de Marseille), et les pings montrent toujours quelques pertes de paquets.
Problème quand même résolu dans l'ensemble.
-
Pour les pings, si c'est vers Google, je remarque la même chose depuis Free, même quand l'usage n'est pas réellement impacté.
Pour la géolocalisation de l'IP, ce n'est pas anormal, la géolocalisation est rarement exacte surtout que ce sont des plages IP précédemment attribuées aux connexion ADSL non-dégroupées, pour lesquelles GeoIP ne fonctionnait pas.
Et pour l'upload, le problème a tout simplement dû être résolu.