La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Débit fibre => Discussion démarrée par: calisto le 24 février 2022 à 12:46:49
-
Bonjour
Possédant une livebox3 et un boitier fibre noire ONT, avec câble ethernet cat 6.0 avec connection 400/400 mega.
Depuis le début de l’installation de la fibre, j'ai remarqué qu'il y avait une limitation dans le téléchargements de fichiers, la limitation se situe entre 0.5mo/s et 5mo/s (4Mb/s et 20Mb/s) en fonction des serveurs et ceci à tout moment. Par exemple, les fichiers de 1G;10G de tests de bande passante sur les divers sites que l'on peut trouver.
Sous windows 10, en ayant déactivé toutes les fonctions de limitation de débits, ainsi qu'en mode sans échec, sous linux, sur un autre PC, formaté le SSD, rien ne change.
Par contre sur speedtest https://www.speedtest.net/fr en mode "multi" j'ai bien ma bande passante de 400Mega, par contre en "unique" celà n'est que de 100Mega, pareil sur les deux PC.
Et si je télécharge les fichiers tests de 1G ou 10G avec Jdownloader avec l'option de "connections max de 20 download simultanés, j'ai la vitesse du fichier x20.
J'en conclus que si j'obtiens bien 400méga au speedtest en mode "multi," c'est que le débit fibre entrant chez moi correspond.
Mais qu'il y a une limitation du débit par connections TCP. Quelle pourrait être la cause ?
Limitation chez orange ?
Bug de la livebox ou du boitier ONT ?
Incompatibilité entre la livebox, le boitier ONT, et windows10 ou linux ?
Problème de drivers ?
:'(
-
je pense que c'est comme ça pour tout le monde. les résultats sont moins bon pour moi aussi, 814Mbps au lieu de 942Mbps habituellement.
Depuis Windows XP, et les modems 56K, les logiciels du genre TCPoptimizer (https://www.speedguide.net/downloads.php) n'ont jamais rien changé chez moi. et Meme pire, sur un windows server 2008 (à l'époque) cela avait meme foutu un bordel monstre...
Je ne crois pas que "Orange limite le débit par session TCP"
-
je pense que c'est comme ça pour tout le monde. les résultats sont moins bon pour moi aussi, 814Mbps au lieu de 942Mbps habituellement.
Depuis Windows XP, et les modems 56K, les logiciels du genre TCPoptimizer (https://www.speedguide.net/downloads.php) n'ont jamais rien changé chez moi. et Meme pire, sur un windows server 2008 (à l'époque) cela avait meme foutu un bordel monstre...
Je ne crois pas que "Orange limite le débit par session TCP"
Si tu lis bien , ce n'est pas un problème de fourniture du débit, les speed tests en mode "multi" sont parfaits.
Mais je constate bien en une unique connection TCP, que le débit est bridé par une division par 10 voir plus/
-
j'ai bien lu ! mais ce probleme je le constate depuis longtemps, je ne saurais expliquer la raison, mais si sur speedtest ils ont vu qu'il était necessaire de faire un mode "multi" c'est que eux ils ont aussi constaté le phénomène et peut etre même qu'ils savent "pourquoi".
franchement, avis perso, je ne crois pas à un bridage côté FAI.
Chez SFR mon débit n'est pas /10 mais il est bien présent. 800Mbps vs 940Mbps
Voilà un début d'explication que j'ai trouvé:
https://www.quora.com/Can-you-achieve-full-download-speed-on-single-threaded-connection-to-a-far-away-server-instead-of-using-multi-threaded-download-accelrator-networking-download-internet-connection-bandwidth-speedtest-admin
En fait il faudrait que le test soit fait en UDP, pas en TCP. Et là encore il doit y avoir une raison s'ils ne l'ont pas fait jusqu'a maintenant.
Ha tien, regarde ce thread : https://lafibre.info/1gb-free/cherche-testeurs/
-
Je recommence parce que mon message a sauté…
Je disais donc que je viens de faire le test en MONO connection dont le résultat est ci-dessous à sur un iPad Pro en Wifi donc. Bien loin des 20 Mbps de l’auteur du fil.
Et pour préciser le contexte: je n’utilise pas de Livebox mais un EdgeRouter ER4 et des bornes wifi Ubiquiti U6-Lite.
-
Pas de bridage côté réseau Orange sur de la mono session.
De mon côté, avec Livebox 5, en mono session ça donne 907 Mbps down, 578 Mbps up.
-
Je recommence parce que mon message a sauté…
Je disais donc que je viens de faire le test en MONO connection dont le résultat est ci-dessous à sur un iPad Pro en Wifi donc. Bien loin des 20 Mbps de l’auteur du fil.
Et pour préciser le contexte: je n’utilise pas de Livebox mais un EdgeRouter ER4 et des bornes wifi Ubiquiti U6-Lite.
En mono-session je suis à 100mega soit 10mo/s. Mais en "multi" c'est parfait c'est bien 400mega soit 50mo/s.
Mais c'est en téléchargeant des fichiers sur tous sites confondus que je constate des limitations, par exemple https://speed.hetzner.de/10GB.bin oscille entre 2mo/s et 3mo/s avec firefox ou internetExplorer. Avec Jdownloader vu que l'on peut paramétrer 20connectiosn en même temps, j'obtiens bien environ 2mo/s x 20 = 40 mo/s.
Certains autres fichiers sont encore plus mauvais.
Je vais étudier les liens postés par Cetipabo
@Cetipabo, ce n'est pas speedtest qui a choisit le mode unique ou multi, c'est bien moi qui a le choix.
-
@Cetipabo, ce n'est pas speedtest qui a choisit le mode unique ou multi, c'est bien moi qui a le choix.
j'ai dit que c'etait speedtest qui choisissait ? ???
-
j'ai bien lu ! mais ce probleme je le constate depuis longtemps, je ne saurais expliquer la raison, mais si sur speedtest ils ont vu qu'il était necessaire de faire un mode "multi" c'est que eux ils ont aussi constaté le phénomène et peut etre même qu'ils savent "pourquoi".
franchement, avis perso, je ne crois pas à un bridage côté FAI.
Chez SFR mon débit n'est pas /10 mais il est bien présent. 800Mbps vs 940Mbps
Sans exclure les autres explications déjà avancées, il faut considérer le point suivant.
La plupart des puces sur carte réseau ont désormais plusieurs tampons qui ne sont pas utilisés par une même connexion TCP. Au-delà, il y a des algorithmes subtils pour savoir quel(s) coeur-cpu(s) traite(nt) quoi mais si dès le point de départ le trafic n'est pas réparti sur l'ensemble des capacités de traitement de la carte alors on ne peut atteindre les performances les plus élevées dont le matériel est capable. Avec plusieurs connexions TCP on change la donne.
Néanmoins il est possible que certains possèdent du matériel apte à traiter les presque 1Gbit/s d'un débit limité par FAI sur une seule connexion TCP, tout le monde n'observera donc pas la même chose.
Ca ne répond pas à l'OP mais j'espère que ça rend le point précédent plus clair.
-
En mono-session je suis à 100mega soit 10mo/s. Mais en "multi" c'est parfait c'est bien 400mega soit 50mo/s.
Mais c'est en téléchargeant des fichiers sur tous sites confondus que je constate des limitations, par exemple https://speed.hetzner.de/10GB.bin oscille entre 2mo/s et 3mo/s avec firefox ou internetExplorer. Avec Jdownloader vu que l'on peut paramétrer 20connectiosn en même temps, j'obtiens bien environ 2mo/s x 20 = 40 mo/s.
Certains autres fichiers sont encore plus mauvais.
Je vais étudier les liens postés par Cetipabo
@Cetipabo, ce n'est pas speedtest qui a choisit le mode unique ou multi, c'est bien moi qui a le choix.
Je viens de tester https://speed.hetzner.de/10GB.bin à l'instant sous Firefox.
-
Merci, donc je ne vois pas d'où pourrait venir le problème, peut-être d'une limitation du FAI, d'un bug de la box ou du boitier ONT.
-
peut-être d'une limitation du FAI
Orange ? Non.
-
Je viens de tester https://speed.hetzner.de/10GB.bin à l'instant sous Firefox.
Donc d'où peut venir le problème, surtout que le speedtest en multi est parfait, alors que celui en mono est divisé par 3.
-
Donc d'où peut venir le problème, surtout que le speedtest en multi est parfait, alors que celui en mono est divisé par 3.
A moins d'envisager l'aberration qui ferait qu'Orange aurait pris des cours chez Free :o , il ne faut pas exclure une limitation au niveau interne du paramétrage de la pile IP de la machine qui fait le test...
Ceci sauf si le test est parfaitement reproducible sur d'autres machines!
Les coupeurs de bit en 4 devraient vous apporter plus d'éclaircissements sur le sujet... ;)
-
A moins d'envisager l'aberration qui ferait qu'Orange aurait pris des cours chez Free :o , il ne faut pas exclure une limitation au niveau interne du paramétrage de la pile IP de la machine qui fait le test...
Ceci sauf si le test est parfaitement reproducible sur d'autres machines!
Les coupeurs de bit en 4 devraient vous apporter plus d'éclaircissements sur le sujet... ;)
Testé sur 2 machines, en mode sans échec, 2 OS différents, ça fait bcp. Et à ces vitesses le CPU et la carte réseau ne sont pas vraiment des facteurs limitants. D’autant plus que le débit est atteint en multi. Donc si problème local il y a il vient d’ailleurs sur le LAN (même carte réseau? Livebox qui déconne? Un switch ou un routeur quelques part?)
-
Testé chez Soh, pas de limitation, sauf celle de mon débit contractuel 300/300
et encore là je dépasse un peu moyenne de 200Mb
LB4 avec adaptateur SFP
Donc, non Orange ne bride pas
-
faudrait juste trouver une explication à pourquoi un FAI briderai 1 connexion et pas l'ensemble ? brider le débit total je peux comprendre, mais brider 1 connexion tout en laissant la possibilité d'atteindre le débit max sur plusieurs....je ne vois pas.
j'ai posté un lien vers une explication sur la page précédente.
TCP throughput is impacted significantly by latency irrespective of threading or any other techniques you might be using.
If everything aligns correctly you can get a mathematically perfect connection and get the maximum throughput given the latency you’re dealing with. However, in most cases you will probably get higher aggregate throughput with threaded connections because not all of them will experience the same congestion problems at the same time.
Concretely, lets say you have 1% packet loss to a server in China. If you lose 1/100 packets on a single TCP stream that going to severely reduce your thoughput due to retransmission. If you have 10 sockets running and still lose 1%, only one of those streams will be directly impacted by the loss at a time, so you can utilize more bandwidth in parallel on average.
s'il y avait moyen de faire un test en UDP, donc sans retransmission de paquets, le resultat devrait etre au MAX sur une connexion.
-
Testé sur 2 machines, en mode sans échec, 2 OS différents, ça fait bcp. Et à ces vitesses le CPU et la carte réseau ne sont pas vraiment des facteurs limitants. D’autant plus que le débit est atteint en multi. Donc si problème local il y a il vient d’ailleurs sur le LAN (même carte réseau? Livebox qui déconne? Un switch ou un routeur quelques part?)
Il ne faut jamais exclure le "mauvais vieux" logiciel sournois, qu'il suffit d'avoir installé une fois sur les 2 machines pour modifier le paramétrage de la pile IP, impactant seulement TCP via la modification de certains tampons mémoire. Si je ne me trompe, une fois ce paramétrage modifié, pas sûr que même en mode sans échec il n'y ait pas de répercussions...
Par ailleurs, il me semble bien que le choix du mode mono ou multi de speedtest n'est pas accessible dans toutes ses interfaces, Navigateur, Application ou Mobile...
Quant aux tests en UDP, cela a déjà été évoqué et son intérêt semble plus que limité!
-
Quant aux tests en UDP, cela a déjà été évoqué et son intérêt semble plus que limité!
alors ca je demande a voir.
l'UDP va enlever de l'equation les retransmissions de paquets perdus ou corrompus en cours de route. si ce qu'on souhaite c'est juste obtenir le meilleur débit possible pour se rapprocher de son débit théorique, il est inutile d'ajouter dans l'equation la "qualité" du débit. je parle juste pour le cas actuel. pour essayer d'etablir la raison de cet écart entre single et multi.
Moi je le vois comme ça. ::)
tien au passage, il existe un outil capable de comptabiliser le volume qui a été retransmis sur notre réseau ou notre PC ? genre au bout d'une heure, une journée, X Mega ou Giga ont necessité une retransmission. je suis sur qu'on serait tous très surpris du résultat.
-
alors ca je demande a voir.
l'UDP va enlever de l'equation les retransmissions de paquets perdus ou corrompus en cours de route. si ce qu'on souhaite c'est juste obtenir le meilleur débit possible pour se rapprocher de son débit théorique, il est inutile d'ajouter dans l'equation la "qualité" du débit. je parle juste pour le cas actuel. pour essayer d'etablir la raison de cet écart entre single et multi.
Moi je le vois comme ça. ::)
Avec de l'UDP, on aura normalement toujours le max de la connexion, même si on perd une bonne partie de "l'utile".
Ce qui est important, et qui a provoqué le post original est bien la limitation par connexion TCP.
Limitation que l'on retrouve sur d'autres interventions hors Orange, entre autres sur un sujet largement débattu, le fameux ONU V2 de Free, qui ne pose aucun problème en UDP, mais uniquement en TCP, en limitant le débit par connexion TCP... C'est le pourquoi de ma "sortie" sur l'UDP!
-
OK @fansat70, capito ;)
Sur l'historique des tests sur nperf, je vois qu'il y a un paramettre auquel je n'avais jamais fait attention, "%perte".
(https://i.imgur.com/yukslBw.png)
on voit d'ailleurs un 10% dans mon cas pour un speedtest sur Marseille, je trouve ça énorme...
ha ce serait peut etre l'ecart entre moy et max...
ben non, on dirait bien une perte de paquets, on le voit sur un résultat de speedtest :
(https://i.imgur.com/6nXL1Th.png)
-
OK @fansat70, capito ;)
Sur l'historique des tests sur nperf, je vois qu'il y a un paramettre auquel je n'avais jamais fait attention, "%perte".
(https://i.imgur.com/yukslBw.png)
on voit d'ailleurs un 10% dans mon cas pour un speedtest sur Marseille, je trouve ça énorme...
ha ce serait peut etre l'ecart entre moy et max...
C'est toute la problématique des tests avec les différents outils... Certains masquent une partie des choses, et surtout comment elles sont faites.
Certains outils utilisent et du TCP, et de l'UDP pour entre autres les vidéos... La quantification dans tout cela et les moyennes plus ou moins peaufinées et/ou orientées, gulp!
Ce que je retiens est la possibilité pour certains utilisateurs de télécharger plus ou moins vite depuis les sites qui leur conviennnet, et pour une énorme proportion, ces téléchargement se font en TCP, et en mono-connexion...
Dans le cas soumis au départ, la question est: où peut-être le schmürtz en TCP, s'il y en a un! Ensuite, on peut "s'amuser" en dérivant plus ou moins, mais le but des interventions dans ce sujet ne serait-il pas de trouver le loup? Et la description du problème est à mon humble avis suffisamment précise pour éviter de se disperser à droite et à gauche. Ceci même si de mon côté, je suis pas à même de trouver exactement où se trouve le loup, ce que je regrette!
-
Rappel je ne suis pas impacté à 10%, mais bien par au moins 90%. Je connais toute même les bases des réseaux internet et comment windows10 pourrait impacter le débit, pour résoudre les problèmes basiques. Cependant là je sèche, je penche plutôt un bug de la box ou du boitier ONT tout comme chez free.
Voilà un autre test sur site étranger, celui-ci un des pire : https://speedtest-ny.turnkeyinternet.net/10000mb.bin
dans les 670ko/s (5mega) dans firefox.
Et dans jdownloader avec une connection multi x20, j'ai dans les 13mo/s (105 Mega) on a bien la base de la monoconnection : 0.670*20 = 13Mo/s.
-
Je viens de tester, ça tourne aux alentours de 200 Mbps.
Mais bon un test sur un serveur aux US bof ....
Tu as essayé en mode sans échec ? avec un autre PC ?
Ca donne quoi sur https://appliwave.testdebit.info/10G/10G.iso (https://appliwave.testdebit.info/10G/10G.iso)
-
Déjà fais tous tes tests sous Linux, ça réglera l'aspect problème logiciel de PC.
Ensuite, as-tu la possibilité de faire le test avec la même machine sur une autre connexion fibre Orange ?
Car moi en connexion unique ou multiple, j'ai tout le temps 950 Mbps. Même sur le programme checkBugOnuFree.pl les tests Cubic et BBR sont tout le temps à 950 Mbps :/
-
@ calisto, au passage, complète ton profil.
-
Je viens de tester, ça tourne aux alentours de 200 Mbps.
Mais bon un test sur un serveur aux US bof ....
Tu as essayé en mode sans échec ? avec un autre PC ?
Ca donne quoi sur https://appliwave.testdebit.info/10G/10G.iso (https://appliwave.testdebit.info/10G/10G.iso)
Oui en mode sans echec, deplus sur un autre PC ainsi que LINUX sur les deux PC ,donnent le même résultat, c'est pour celà que je pense à un bridage d'un quelconque bug sur la livebox ou l'ONT, voir un bridage je ne sais pour quelle raison dans l'armoire fibre ou chez le FAI.
Le dernier speedtest sur appliwave: 4.5mo/s :
-
Oui en mode sans echec, deplus sur un autre PC ainsi que LINUX sur les deux PC ,donnent le même résultat, c'est pour celà que je pense à un bridage d'un quelconque bug sur la livebox ou l'ONT, voir un bridage je ne sais pour quelle raison dans l'armoire fibre ou chez le FAI.
Le dernier speedtest sur appliwave: 4.5mo/s :
Un bridage chez Orange? A ma connaissance, cela n'a jamais été à l'ordre du jour...
Un problème avec un équipement intermédiaire entre les bécanes et la box... Je ne me souviens pas avoir entendu parler d'un routeur ou un switch avec des "angoisses"...
Un problème avec la box? Pas impossible! Un problème de jarretière fibre ou une fibre coincée/pliée? Pas impossible non plus! Un module SFP+ défectueux, idem...
Mais uniquement sur un flux TCP, je me dirigerais sur la box... On alors, en dernier recours, changer de troll personnel, et en trouver un bien dressé... ;)
-
S'il y avait un bridage côté réseau Orange ça se saurait et tout le monde aurait le même problème y compris moi.
Et ce n'est pas le cas.
Sans remettre en cause la Livebox, pourquoi avoir gardé une LB 3 sur une offre Livebox 400 Mbps et ne pas être passé sur la LB 5 ?
-
@Fransat, lors de l'installation fibre, j'ai demandé la valeur de l’atténuation qui était de -15dbm.
Deplus je rappelle que le speedtest en multi est parfait !
Simplement je rencontre des ralentissements lors de download.
@TI@RI, lors la souscription ADSL-->Fibre, le conseiller m'a dit de garder la LB3 et ils m'ont envoyé un boitier fibre ONT.
-
@Fransat, lors de l'installation fibre, j'ai demander la valeur de l’atténuation qui était de -15db.
Deplus je rappelle que le speedtest en multi est parfait !
Simplement je rencontre des ralentissements lors de download.
@TI@RI, lors la souscription ADSL-->Fibre, le conseiller m'a dit de garder la LB3 et ils m'ont envoyé un boitier fibre ONT.
ONT Orange et ONU Free, même combat? Pas les mêmes techno en amont et médias en aval... Là, je ne vois pas... On en revient à la box, et peut-être une mise à jour sur la LB3 pas spécialement heureuse? :-[
-
lors de l'installation fibre, j'ai demander la valeur de l’atténuation qui était de -15db.
Ce ne serait pas plutôt le niveau reçu en dBm ?
-
oui dBm j'ai modifié.
-
j'ai demandé la valeur de l’atténuation qui était de -15dbm.
Sauf que ce n'est pas une atténuation, qui elle s'exprime en dB, mais le niveau de puissance reçue
-
Ensuite, as-tu la possibilité de faire le test avec la même machine sur une autre connexion fibre Orange ?
#redface
-
que donne ces tests: https://nspeed.app/wintest.html
également avec iperf3 en udp:
iperf3 pour Windows: https://files.budman.pw/iperf3.10.1_64bit.zip
puis demander l'envoi d'un flux a X Mbps. X étant le débit max de la ligne - 10% environ. Donc sur un abonnement 400Mbps par exemple, demander 360Mbps avec cette commande:
./iperf3.exe -c bouygues.testdebit.info -p 9238 -u -R -b 360M
(si le serveur est trop occupé sur le port 9238, choisir un autre port entre 9200 et 9240)
-
de mon coté avec la commande iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 900M
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 900M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 58816 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 77.2 MBytes 648 Mbits/sec 0.033 ms 23039/78489 (29%)
[ 5] 1.00-2.00 sec 77.1 MBytes 647 Mbits/sec 0.044 ms 24077/79432 (30%)
[ 5] 2.00-3.00 sec 73.6 MBytes 617 Mbits/sec 0.023 ms 24236/77079 (31%)
[ 5] 3.00-4.00 sec 75.0 MBytes 629 Mbits/sec 0.011 ms 23243/77079 (30%)
[ 5] 4.00-5.00 sec 75.6 MBytes 634 Mbits/sec 0.010 ms 22761/77067 (30%)
[ 5] 5.00-6.00 sec 76.1 MBytes 638 Mbits/sec 0.036 ms 22365/76999 (29%)
[ 5] 6.00-7.00 sec 76.0 MBytes 638 Mbits/sec 0.039 ms 22464/77064 (29%)
[ 5] 7.00-8.00 sec 80.2 MBytes 673 Mbits/sec 0.033 ms 19468/77046 (25%)
[ 5] 8.00-9.00 sec 76.9 MBytes 645 Mbits/sec 0.042 ms 21802/77050 (28%)
[ 5] 9.00-10.00 sec 89.9 MBytes 754 Mbits/sec 0.015 ms 12526/77081 (16%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.07 sec 1.05 GBytes 900 Mbits/sec 0.000 ms 0/775657 (0%) sender
[ 5] 0.00-10.00 sec 778 MBytes 652 Mbits/sec 0.015 ms 215981/774386 (28%) receiver
iperf Done.28% de lost coté receiver, ca fait beaucoup dit donc :(
-
Test identique réalisé à l'instant sur une connexion Free... 16% perte sur Receiver...
Cela ne veut pas dire charrette... D'autres peuvent faire le même test? Quel que soit l'opérateur, mais avec la même cible?
-
Même commande que vous deux sur mon accès FTTH Orange 2G/600...
-
@vanilu76 tu n'aurais pas un problème par hasard ?? ;D ;D 97% de pertes....t'es en wifi ?
-
Justement je ne comprends pas, aucun problème de débit en général, également sur les tests réalisés ici sauf celui-là. Je suis bien en ethernet.
EDIT : C'est mieux avec une autre version de iperf
-
Bonsoir,
ma contribution et aussi mon premier post sur le forum :D
Test PC sous Linux en ethernet 1G
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.2.138 port 38254 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 98.5 MBytes 827 Mbits/sec 0.031 ms 6319/77674 (8.1%)
[ 5] 1.00-2.00 sec 107 MBytes 900 Mbits/sec 0.018 ms 0/77690 (0%)
[ 5] 2.00-3.00 sec 107 MBytes 899 Mbits/sec 0.020 ms 108/77693 (0.14%)
[ 5] 3.00-4.00 sec 107 MBytes 900 Mbits/sec 0.020 ms 0/77707 (0%)
[ 5] 4.00-5.00 sec 107 MBytes 900 Mbits/sec 0.021 ms 0/77682 (0%)
[ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec 0.023 ms 0/77683 (0%)
[ 5] 6.00-7.00 sec 101 MBytes 847 Mbits/sec 0.044 ms 4290/77446 (5.5%)
[ 5] 7.00-8.00 sec 108 MBytes 903 Mbits/sec 0.010 ms 56/77970 (0.072%)
[ 5] 8.00-9.00 sec 107 MBytes 900 Mbits/sec 0.020 ms 0/77674 (0%)
[ 5] 9.00-10.00 sec 107 MBytes 899 Mbits/sec 0.017 ms 0/77639 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 1.05 GBytes 900 Mbits/sec 0.000 ms 0/777743 (0%) sender
[ 5] 0.00-10.00 sec 1.03 GBytes 887 Mbits/sec 0.017 ms 10773/776858 (1.4%) receiver
-
Hello.
Ma contribution, connexion Orange 2.5G/600M (je limite à 2.25). PC sous linux. Zéro problème:
$ iperf3 -4 -c bouygues.testdebit.info -p 9222 -u -R -b 2250M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local x.x.x.x port 47834 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 222 MBytes 1.87 Gbits/sec 0.006 ms 31704/192739 (16%)
[ 5] 1.00-2.00 sec 268 MBytes 2.25 Gbits/sec 0.003 ms 1306/195557 (0.67%)
[ 5] 2.00-3.00 sec 268 MBytes 2.25 Gbits/sec 0.005 ms 100/194215 (0.051%)
[ 5] 3.00-4.00 sec 267 MBytes 2.24 Gbits/sec 0.004 ms 945/194264 (0.49%)
[ 5] 4.00-5.00 sec 267 MBytes 2.24 Gbits/sec 0.005 ms 557/194212 (0.29%)
[ 5] 5.00-6.00 sec 268 MBytes 2.24 Gbits/sec 0.004 ms 440/194232 (0.23%)
[ 5] 6.00-7.00 sec 268 MBytes 2.25 Gbits/sec 0.053 ms 109/194270 (0.056%)
[ 5] 7.00-8.00 sec 268 MBytes 2.25 Gbits/sec 0.004 ms 151/194210 (0.078%)
[ 5] 8.00-9.00 sec 268 MBytes 2.25 Gbits/sec 0.005 ms 95/194227 (0.049%)
[ 5] 9.00-10.00 sec 268 MBytes 2.25 Gbits/sec 0.003 ms 17/194243 (0.0088%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 2.62 GBytes 2.25 Gbits/sec 0.000 ms 0/1942736 (0%) sender
[ 5] 0.00-10.00 sec 2.57 GBytes 2.21 Gbits/sec 0.003 ms 35424/1942169 (1.8%) receiver
iperf Done.
-
Si je résume...
Le test étant fait en UDP, il y a un équipement dans la trajectoire qui pose problème pour ceux qui ont des pertes sensibles avec ce test...
Le receiver étant le PC qui a déclenché le test, il peut aussi poser problème ("j'arrive pas à avaler tout ce que l'on m'envoie!"), ou la box ("P'T1, ma CPU ne suit pas, parce que l'on lui en demande trop par ailleurs!"), ou un autre équipement "actif" sur la trajectoire... :-[
-
en baissant le débit progressivement, de 900M a 500M par exemple, si le pourcentage de perte reste le meme ca voudrait dire que le probleme n'est pas sur le PC. et a contrario que le problème est possiblement sur le PC...à voir.
-
Si je résume...
Le test étant fait en UDP, il y a un équipement dans la trajectoire qui pose problème pour ceux qui ont des pertes sensibles avec ce test...
Le receiver étant le PC qui a déclenché le test, il peut aussi poser problème ("j'arrive pas à avaler tout ce que l'on m'envoie!"), ou la box ("P'T1, ma CPU ne suit pas, parce que l'on lui en demande trop par ailleurs!"), ou un autre équipement "actif" sur la trajectoire... :-[
Je viens de faire toute une série de tests, non pas en UDP, mais en TCP, en limitant le débit avec le -b, toujours en reverse mode, le PC étant Receiver.
Ce qui est intéressant est que IPerf3 dans ce mode indique le nombre de retry, le receiver n'ayant pas reçu correctement la trame, et demandant le renvoi.
Les test ont commencé en limitant à 900M (carte ethernet 1Gb) et tant que j'ai eu un nombre de retry significatif, j'ai fait un nouveau test, en descendant le débit...
J'ai un vieille bécane de 2014, et les résultats sont les suivants, en réduisant à chaque fois de 100M le débit:
à 900M, plus de 2000 retry, et ceux-ci on descendu très lentement, au fur et à mesure de la réduction de débit. Ils était encore à 1800 à 200M, et enfin à 100M, plus de retry, ceci de façon répétitive...
J'aurais tendance à conclure que la gestion de mon W10 avec un I7 de 2014 avec 16Go de mémoire et son chipset Ethernet intégré à la carte mère (ASUS Maximus VII Hero) ne savent pas faire plus, en exploitation "standard" (je ne suis pas en mode sans échec...)
Si ma contribution peut apporter quelque chose...
-
de mon côté, test en UDP à 900M, 800M, 700M, 600M, 500M
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 900M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 53380 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 87.5 MBytes 734 Mbits/sec 0.011 ms 16772/79604 (21%)
[ 5] 1.00-2.00 sec 92.8 MBytes 778 Mbits/sec 0.061 ms 10824/77461 (14%)
[ 5] 2.00-3.00 sec 87.3 MBytes 732 Mbits/sec 0.044 ms 14450/77132 (19%)
[ 5] 3.00-4.00 sec 93.8 MBytes 787 Mbits/sec 0.010 ms 9684/77036 (13%)
[ 5] 4.00-5.00 sec 92.8 MBytes 779 Mbits/sec 0.022 ms 10360/77035 (13%)
[ 5] 5.00-6.00 sec 91.9 MBytes 771 Mbits/sec 0.034 ms 11099/77101 (14%)
[ 5] 6.00-7.00 sec 94.6 MBytes 794 Mbits/sec 0.012 ms 9080/77018 (12%)
[ 5] 7.00-8.00 sec 94.8 MBytes 795 Mbits/sec 0.038 ms 8944/77015 (12%)
[ 5] 8.00-9.00 sec 98.9 MBytes 829 Mbits/sec 0.043 ms 6114/77130 (7.9%)
[ 5] 9.00-10.00 sec 105 MBytes 882 Mbits/sec 0.010 ms 1559/77037 (2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 1.05 GBytes 900 Mbits/sec 0.000 ms 0/774808 (0%) sender
[ 5] 0.00-10.00 sec 939 MBytes 788 Mbits/sec 0.010 ms 98886/773569 (13%) receiver
iperf Done.
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 800M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 57924 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 78.8 MBytes 661 Mbits/sec 0.024 ms 12365/68958 (18%)
[ 5] 1.00-2.00 sec 78.7 MBytes 660 Mbits/sec 0.031 ms 14141/70666 (20%)
[ 5] 2.00-3.00 sec 77.6 MBytes 651 Mbits/sec 0.035 ms 12728/68490 (19%)
[ 5] 3.00-4.00 sec 79.2 MBytes 664 Mbits/sec 0.048 ms 11704/68551 (17%)
[ 5] 4.00-5.00 sec 79.7 MBytes 669 Mbits/sec 0.037 ms 11192/68436 (16%)
[ 5] 5.00-6.00 sec 81.2 MBytes 681 Mbits/sec 0.039 ms 10209/68494 (15%)
[ 5] 6.00-7.00 sec 77.3 MBytes 648 Mbits/sec 0.033 ms 12982/68493 (19%)
[ 5] 7.00-8.00 sec 78.8 MBytes 661 Mbits/sec 0.037 ms 11924/68493 (17%)
[ 5] 8.00-9.00 sec 76.0 MBytes 637 Mbits/sec 0.036 ms 13953/68501 (20%)
[ 5] 9.00-10.00 sec 86.2 MBytes 723 Mbits/sec 0.012 ms 6629/68534 (9.7%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 959 MBytes 800 Mbits/sec 0.000 ms 0/688722 (0%) sender
[ 5] 0.00-10.00 sec 793 MBytes 666 Mbits/sec 0.012 ms 117827/687616 (17%) receiver
iperf Done.
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 700M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 57925 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 81.2 MBytes 681 Mbits/sec 0.040 ms 4454/62770 (7.1%)
[ 5] 1.00-2.00 sec 81.9 MBytes 687 Mbits/sec 0.046 ms 1136/59926 (1.9%)
[ 5] 2.00-3.00 sec 81.2 MBytes 681 Mbits/sec 0.045 ms 1595/59933 (2.7%)
[ 5] 3.00-4.00 sec 82.3 MBytes 691 Mbits/sec 0.015 ms 767/59907 (1.3%)
[ 5] 4.00-5.00 sec 81.5 MBytes 683 Mbits/sec 0.045 ms 1440/59955 (2.4%)
[ 5] 5.00-6.00 sec 82.0 MBytes 688 Mbits/sec 0.042 ms 971/59882 (1.6%)
[ 5] 6.00-7.00 sec 81.7 MBytes 685 Mbits/sec 0.049 ms 1315/59981 (2.2%)
[ 5] 7.00-8.00 sec 82.7 MBytes 693 Mbits/sec 0.019 ms 540/59902 (0.9%)
[ 5] 8.00-9.00 sec 81.7 MBytes 685 Mbits/sec 0.017 ms 1273/59938 (2.1%)
[ 5] 9.00-10.00 sec 82.4 MBytes 691 Mbits/sec 0.040 ms 754/59954 (1.3%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 840 MBytes 700 Mbits/sec 0.000 ms 0/603107 (0%) sender
[ 5] 0.00-10.00 sec 819 MBytes 687 Mbits/sec 0.040 ms 14245/602148 (2.4%) receiver
iperf Done.
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 600M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 57926 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 71.6 MBytes 600 Mbits/sec 0.040 ms 2288/53694 (4.3%)
[ 5] 1.00-2.00 sec 71.5 MBytes 600 Mbits/sec 0.039 ms 12/51370 (0.023%)
[ 5] 2.00-3.00 sec 71.5 MBytes 600 Mbits/sec 0.039 ms 17/51369 (0.033%)
[ 5] 3.00-4.00 sec 71.4 MBytes 599 Mbits/sec 0.039 ms 59/51370 (0.11%)
[ 5] 4.00-5.00 sec 71.5 MBytes 600 Mbits/sec 0.037 ms 2/51371 (0.0039%)
[ 5] 5.00-6.00 sec 71.5 MBytes 600 Mbits/sec 0.039 ms 9/51371 (0.018%)
[ 5] 6.00-7.00 sec 71.5 MBytes 600 Mbits/sec 0.038 ms 0/51371 (0%)
[ 5] 7.00-8.00 sec 71.5 MBytes 600 Mbits/sec 0.040 ms 2/51367 (0.0039%)
[ 5] 8.00-9.00 sec 71.5 MBytes 600 Mbits/sec 0.036 ms 0/51369 (0%)
[ 5] 9.00-10.00 sec 71.5 MBytes 600 Mbits/sec 0.038 ms 4/51370 (0.0078%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 720 MBytes 600 Mbits/sec 0.000 ms 0/516843 (0%) sender
[ 5] 0.00-10.00 sec 715 MBytes 600 Mbits/sec 0.038 ms 2393/516022 (0.46%) receiver
iperf Done.
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 500M
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 64931 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 59.6 MBytes 500 Mbits/sec 0.051 ms 1649/44487 (3.7%)
[ 5] 1.00-2.00 sec 59.6 MBytes 500 Mbits/sec 0.050 ms 0/42808 (0%)
[ 5] 2.00-3.00 sec 59.6 MBytes 500 Mbits/sec 0.050 ms 22/42809 (0.051%)
[ 5] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec 0.051 ms 4/42808 (0.0093%)
[ 5] 4.00-5.00 sec 59.6 MBytes 500 Mbits/sec 0.053 ms 5/42808 (0.012%)
[ 5] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec 0.052 ms 21/42808 (0.049%)
[ 5] 6.00-7.00 sec 59.6 MBytes 500 Mbits/sec 0.052 ms 0/42809 (0%)
[ 5] 7.00-8.00 sec 59.6 MBytes 500 Mbits/sec 0.052 ms 0/42807 (0%)
[ 5] 8.00-9.00 sec 59.6 MBytes 500 Mbits/sec 0.053 ms 36/42811 (0.084%)
[ 5] 9.00-10.00 sec 59.6 MBytes 500 Mbits/sec 0.050 ms 5/42809 (0.012%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 599 MBytes 500 Mbits/sec 0.000 ms 0/430445 (0%) sender
[ 5] 0.00-10.00 sec 596 MBytes 500 Mbits/sec 0.050 ms 1742/429764 (0.41%) receiver
iperf Done.
en résumé :
900M = [ 5] 0.00-10.00 sec 939 MBytes 788 Mbits/sec 0.010 ms 98886/773569 (13%) receiver
800M = [ 5] 0.00-10.00 sec 793 MBytes 666 Mbits/sec 0.012 ms 117827/687616 (17%) receiver
700M = [ 5] 0.00-10.00 sec 819 MBytes 687 Mbits/sec 0.040 ms 14245/602148 (2.4%) receiver
600M = [ 5] 0.00-10.00 sec 715 MBytes 600 Mbits/sec 0.038 ms 2393/516022 (0.46%) receiver
500M = [ 5] 0.00-10.00 sec 596 MBytes 500 Mbits/sec 0.050 ms 1742/429764 (0.41%) receiver
Mon PC:
Ryzen 9 3900XT (12C/24T) 3.8GHz - 4.7Ghz
32Go de RAM
Carte réseau intel I211 à 1Gbps.
on voit clairement que pendant le test je n'ai eu que 2 coeurs utilisés:
(https://i.imgur.com/SBfsrBP.png)
Cerise sur le gateau: Iperf depuis mon routeur sous Openwrt, avec 900M.
(https://i.imgur.com/5Z7RzQj.png)
Bon la je pense que c'est clair... sur un test a 900M
1.5% de perte fibre --> Box
17% de perte Box --> PC
-
Bon la je pense que c'est clair... sur un test a 900M
1.5% de perte fibre --> Box
17% de perte Box --> PC
Fait un iperf3 -s sur la box et laisse tourner (ça lance un serveur iperf sur ta box en mode serveur, avec le port par défaut), puis un iperf3.exe -R -c <ip LAN de la box> sur le PC client windows. Iperf permet de faire serveur aussi.
-
Je dois régler le test sur 300 pour avoir un un pourcentage de perte inférieur à 1%.
Comme toi @cetipabo j'ai les deux mêmes cœurs CPU utilisés. J'ai un i5-8300H et c'est pour ça que j'ai beaucoup de perte au-delà de 300, mes 2 cœurs saturent.
-
Fait un iperf3 -s sur la box et laisse tourner (ça lance un serveur iperf sur ta box en mode serveur, avec le port par défaut), puis un iperf3.exe -R -c <ip LAN de la box> sur le PC client windows. Iperf permet de faire serveur aussi.
j'ai un message d'erreur :
root@box:~# iperf3 -s
iperf3: error - unable to start listener for connections: Address in use
iperf3: exiting
haa il faut indiquer un port ! iperf3 -s -p 9999
C:\iperf3>iperf3.exe -R -c 192.168.1.1 -p 9999
Connecting to host 192.168.1.1, port 9999
Reverse mode, remote host 192.168.1.1 is sending
[ 5] local 192.168.1.10 port 24703 connected to 192.168.1.1 port 9999
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 89.5 MBytes 751 Mbits/sec
[ 5] 1.00-2.00 sec 87.5 MBytes 734 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec
[ 5] 3.00-4.00 sec 106 MBytes 890 Mbits/sec
[ 5] 4.00-5.00 sec 110 MBytes 922 Mbits/sec
[ 5] 5.00-6.00 sec 117 MBytes 978 Mbits/sec
[ 5] 6.00-7.00 sec 102 MBytes 858 Mbits/sec
[ 5] 7.00-8.00 sec 121 MBytes 1.01 Gbits/sec
[ 5] 8.00-9.00 sec 99.2 MBytes 832 Mbits/sec
[ 5] 9.00-10.00 sec 110 MBytes 926 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.03 GBytes 888 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.03 GBytes 885 Mbits/sec receiver
iperf Done.J'ai ma femme qui regarde la TV en 1080p à coté ;D donc je ne suis pas seul a consommer du débit.
Mais si je fais le meme test que sur bouygues.testdebit.info en UDP
C:\iperf3>iperf3.exe -c 192.168.1.1 -p 9999 -u -R -b 900M
Connecting to host 192.168.1.1, port 9999
Reverse mode, remote host 192.168.1.1 is sending
[ 5] local 192.168.1.10 port 60481 connected to 192.168.1.1 port 9999
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 72.6 MBytes 609 Mbits/sec 0.006 ms 9122/61293 (15%)
[ 5] 1.00-2.00 sec 72.1 MBytes 605 Mbits/sec 0.004 ms 9484/61292 (15%)
[ 5] 2.00-3.00 sec 72.3 MBytes 607 Mbits/sec 0.007 ms 9324/61277 (15%)
[ 5] 3.00-4.00 sec 72.7 MBytes 610 Mbits/sec 0.003 ms 9102/61326 (15%)
[ 5] 4.00-5.00 sec 72.2 MBytes 605 Mbits/sec 0.012 ms 9479/61299 (15%)
[ 5] 5.00-6.00 sec 72.2 MBytes 606 Mbits/sec 0.006 ms 9481/61335 (15%)
[ 5] 6.00-7.00 sec 73.3 MBytes 615 Mbits/sec 0.017 ms 8660/61320 (14%)
[ 5] 7.00-8.00 sec 72.9 MBytes 611 Mbits/sec 0.012 ms 8951/61305 (15%)
[ 5] 8.00-9.00 sec 72.3 MBytes 606 Mbits/sec 0.005 ms 9367/61271 (15%)
[ 5] 9.00-10.00 sec 76.4 MBytes 641 Mbits/sec 0.008 ms 6432/61328 (10%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 854 MBytes 716 Mbits/sec 0.000 ms 0/613089 (0%) sender
[ 5] 0.00-10.00 sec 729 MBytes 612 Mbits/sec 0.008 ms 89402/613046 (15%) receiver
iperf Done.
et j'ai fait le contraire, iperf3 en serveur sur le PC et en client sur la box :
root@box:~# iperf3 -c 192.168.1.10 -p 9999 -u -R -b 900M
Connecting to host 192.168.1.10, port 9999
Reverse mode, remote host 192.168.1.10 is sending
[ 5] local 192.168.1.1 port 37363 connected to 192.168.1.10 port 9999
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 74.1 MBytes 621 Mbits/sec 0.018 ms 0/53193 (0%)
[ 5] 1.00-2.00 sec 73.2 MBytes 614 Mbits/sec 0.018 ms 0/52576 (0%)
[ 5] 2.00-3.00 sec 74.3 MBytes 623 Mbits/sec 0.021 ms 212/53546 (0.4%)
[ 5] 3.00-4.00 sec 74.1 MBytes 622 Mbits/sec 0.024 ms 288/53537 (0.54%)
[ 5] 4.00-5.00 sec 74.1 MBytes 622 Mbits/sec 0.015 ms 0/53228 (0%)
[ 5] 5.00-6.00 sec 73.0 MBytes 612 Mbits/sec 0.029 ms 0/52406 (0%)
[ 5] 6.00-7.00 sec 75.3 MBytes 632 Mbits/sec 0.016 ms 0/54066 (0%)
[ 5] 7.00-8.00 sec 77.8 MBytes 653 Mbits/sec 0.024 ms 0/55872 (0%)
[ 5] 8.00-9.00 sec 78.3 MBytes 657 Mbits/sec 0.017 ms 0/56217 (0%)
[ 5] 9.00-10.00 sec 77.3 MBytes 649 Mbits/sec 0.025 ms 16/55567 (0.029%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 752 MBytes 631 Mbits/sec 0.000 ms 0/540225 (0%) sender
[ 5] 0.00-10.00 sec 751 MBytes 630 Mbits/sec 0.025 ms 516/540208 (0.096%) receiver
iperf Done.
Ha la par contre je suis a moins de 1%, ce serait pas la version windows de iperf3 qui chie dans la colle ? d'ailleurs les 2 personnes qui semblent avoir un lost super bas sont sous linux.
-
Cela me rappelle une info comme quoi la version Cygwin.dll livrée dans certains packages iperf3 serait daubée...
-
Cela me rappelle une info comme quoi la version Cygwin.dll livrée dans certains packages iperf3 serait daubée...
tu fais référence a ce post ? https://lafibre.info/iperf/maj-iperf-windows/ https://lafibre.info/iperf/lauteur-diperf3-a-propos-diperf-fr/msg783388/#msg783388
-
Bon ben j'ai trouvé, pour windows ajouter -l 8192 dans la commande. Ca va tout de suite mieux ;D
source : https://github.com/esnet/iperf/issues/296#issuecomment-254366111
C:\iperf3>iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 900M -l 8192
warning: UDP block size 8192 exceeds TCP MSS 1460, may result in fragmentation / drops
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 192.168.1.10 port 62465 connected to 89.84.1.186 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 97.2 MBytes 815 Mbits/sec 0.131 ms 1816/14260 (13%)
[ 5] 1.00-2.00 sec 108 MBytes 906 Mbits/sec 0.089 ms 4/13828 (0.029%)
[ 5] 2.00-3.00 sec 107 MBytes 900 Mbits/sec 0.130 ms 0/13733 (0%)
[ 5] 3.00-4.00 sec 107 MBytes 900 Mbits/sec 0.114 ms 0/13733 (0%)
[ 5] 4.00-5.00 sec 107 MBytes 900 Mbits/sec 0.095 ms 0/13732 (0%)
[ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec 0.135 ms 0/13734 (0%)
[ 5] 6.00-7.00 sec 107 MBytes 900 Mbits/sec 0.124 ms 0/13733 (0%)
[ 5] 7.00-8.00 sec 107 MBytes 900 Mbits/sec 0.130 ms 0/13733 (0%)
[ 5] 8.00-9.00 sec 107 MBytes 900 Mbits/sec 0.130 ms 0/13733 (0%)
[ 5] 9.00-10.00 sec 107 MBytes 900 Mbits/sec 0.091 ms 0/13732 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 1.05 GBytes 900 Mbits/sec 0.000 ms 0/138171 (0%) sender
[ 5] 0.00-10.00 sec 1.04 GBytes 892 Mbits/sec 0.091 ms 1820/137951 (1.3%) receiver
iperf Done.
-
Bon ben j'ai trouvé, pour windows ajouter -l 8192 dans la commande. Ca va tout de suite mieux ;D
source : https://github.com/esnet/iperf/issues/296#issuecomment-254366111
[...]
Tout semble dépendre de la carte, du paramétrage de windows... Chez moi:
./iperf3.exe -c bouygues.testdebit.info -p 9222 -u -R -b 900M -l 8192
warning: UDP block size 8192 exceeds TCP MSS 1440, may result in fragmentation / drops
Connecting to host bouygues.testdebit.info, port 9222
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 2a01:e0a:979:81b0:d15c:61a6:acb7:6a85 port 62459 connected to 2001:860:de01:1100::2 port 9222
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.01 sec 16.0 KBytes 130 Kbits/sec 0.063 ms 0/2 (0%)
[ 5] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 3.01-4.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 4.01-5.02 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 5.02-6.00 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 7.00-8.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 8.01-9.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
[ 5] 9.01-10.01 sec 0.00 Bytes 0.00 bits/sec 0.063 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.06 sec 1.05 GBytes 900 Mbits/sec 0.000 ms 0/138184 (0%) sender
[ 5] 0.00-10.01 sec 16.0 KBytes 13.1 Kbits/sec 0.063 ms 0/2 (0%) receiver
iperf Done.
Buurp! Clair que chez moi, cela ne passe pas, le message est clair: warning: UDP block size 8192 exceeds TCP MSS 1440, may result in fragmentation / drops
-
ce warning n'a rien a voir avec UDP... donc n'est peut-etre qu'un bug d'iperf.
par contre si le buffer est trop grand et si la carte de supporte pas la "fragmentation offload" (USO) il est possible qu'au dela de "-l 1472" (en ipv4) et "-l 1452" en IPv6 ca ne marche plus.
fait un test avec -l 1452 puis -l 1453 (ou 1472 et 1473 en IPv4) pour voir.
Sous Windows powershell la commande "Get-NetAdapterChecksumOffload" permet de voir cela,sous Linux c'est avec ethtool (option -k).
-
Exact, en IPV6, l=1452 Ok, mais 1453 ko!
C'est effectivement avec l=1452 que les pertes sont minimisées (6,9%)...
Merci!
-
que donne ces tests: https://nspeed.app/wintest.html
également avec iperf3 en udp:
iperf3 pour Windows: https://files.budman.pw/iperf3.10.1_64bit.zip
puis demander l'envoi d'un flux a X Mbps. X étant le débit max de la ligne - 10% environ. Donc sur un abonnement 400Mbps par exemple, demander 360Mbps avec cette commande:
./iperf3.exe -c bouygues.testdebit.info -p 9238 -u -R -b 360M
(si le serveur est trop occupé sur le port 9238, choisir un autre port entre 9200 et 9240)
Sur ma connection 400M/400M de Orange avec nspeed sur le fichier 10G :
ile nspeed.exe https://dl.nspeed.app/nspeed-client/latest/nspeed_windows_amd64.exe PS C:\Windows\system32> ./nspeed.exe -cpu get http://bouygues.testdebit.info/10G/10G.iso
Jobs:
0 HTTP client {Method: GET, URL: "http://bouygues.testdebit.info/10G/10G.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1:19PM | 21| 19| 23| 16|, active jobs: 0 / active goroutines: 7
1:19PM | 22| 19| 23| 8|, active jobs: 0 / active goroutines: 7
1:19PM | 26| 31| 31| 19|, active jobs: 0 / active goroutines: 7
1:19PM | 26| 19| 22| 8|, active jobs: 0 / active goroutines: 7
1:19PM | 29| 16| 30| 14|, active jobs: 0 / active goroutines: 7
1:19PM | 19| 31| 25| 2|, active jobs: 0 / active goroutines: 7
1:19PM | 26| 31| 30| 14|, active jobs: 0 / active goroutines: 7
1:19PM | 28| 26| 28| 19|, active jobs: 0 / active goroutines: 7
1:19PM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 41.3 Mbps| 0 bps| 7.99| 41.3 MB| 0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 14.709 ms)
Total| 41.3 Mbps| 0 bps| 7.99| 41.3 MB| 0 B|
Et sur Iperf3.exe :
C:\>iperf3.exe -c bouygues.testdebit.info -p 9238 -u -R -b 360M
Connecting to host bouygues.testdebit.info, port 9238
Reverse mode, remote host bouygues.testdebit.info is sending
[ 4] local 2a01:cb10:207:6c00:b474:3d8f:89bd:d4f0 port 61356 connected to 2001:860:de01:1100::2 port 9238
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 2.31 MBytes 19.3 Mbits/sec 560.027 ms 2412/2708 (89%)
[ 4] 1.00-2.00 sec 2.20 MBytes 18.4 Mbits/sec 5.004 ms 5288/5569 (95%)
[ 4] 2.00-3.00 sec 2.21 MBytes 18.5 Mbits/sec 5.819 ms 5395/5678 (95%)
[ 4] 3.00-4.00 sec 2.22 MBytes 18.6 Mbits/sec 5.979 ms 5240/5524 (95%)
[ 4] 4.00-5.00 sec 2.20 MBytes 18.4 Mbits/sec 5.423 ms 5164/5445 (95%)
[ 4] 5.00-6.00 sec 2.23 MBytes 18.7 Mbits/sec 5.300 ms 5173/5458 (95%)
[ 4] 6.00-7.00 sec 2.18 MBytes 18.3 Mbits/sec 4.953 ms 5069/5348 (95%)
[ 4] 7.00-8.00 sec 2.15 MBytes 18.0 Mbits/sec 4.627 ms 5179/5454 (95%)
[ 4] 8.00-9.00 sec 2.16 MBytes 18.1 Mbits/sec 5.690 ms 5347/5624 (95%)
[ 4] 9.00-10.00 sec 2.21 MBytes 18.6 Mbits/sec 4.784 ms 5289/5572 (95%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 431 MBytes 362 Mbits/sec 4.625 ms 49613/52440 (95%)
[ 4] Sent 52440 datagrams
iperf Done.
mauvais concernant le débit, le jitter, les paquets perdus.
Mon processeur était dans les 30%.
-
ca ressemble a du débit wifi quand meme.
que donne les 2 commandes indiquées dans https://nspeed.app/wintest.html et le test nspeed avec -n 4 ?
-
moi je pense qu'iperf3 sous windows déconne au dela de 200Mbps.
-
moi je pense qu'iperf3 sous windows déconne au dela de 200Mbps.
ca dépend de la machine d'ou le test avec nspeed.
-
je viens d'installer debian11 sur un mini pc HP prodesk 600G1 avec un I5 6500T, donc bien moins puissant que mon PC Ryzen 9.
zero tweak ou optimisation. J'enchaine sur le test iperf3 de suite après install de l'OS et du package. Le PC branché sur le meme cable réseau.
J'ai donc environ 30% de lost avec windows 11
et là 0.99% sur la Debian 11
(https://i.imgur.com/jkc3qVP.png)
Proche de ce que j'avais en faisant le test directement sur le routeur :
(https://i.imgur.com/5Z7RzQj.png)
-
Qu'en dire? Qu'il y aurait un "schmürtz" au niveau de tous les Ouindauze qui sont connectés sur cette box bien précise?
Pas certain, il faut lever le doute en réalisant pas seulement un test à une heure donnée, mais une batterie sur les 2 systèmes.
Si l'on obtient une certitude de OK sur le Debian Frais et pas OK sur le W10, (hypothèse farfelue, évidemment!) serait-ce que tous les ouindauze seraient "squizzés" par le même logiciel sournois?
-
ca ressemble a du débit wifi quand meme.
que donne les 2 commandes indiquées dans https://nspeed.app/wintest.html et le test nspeed avec -n 4 ?
Je ne suis pas en wifi, mais bien en ethernet 6.0 débit : théorique 400M/400M.Et je rappelle que c'est le but su topic, j'ai un problème de débit en mode mono-session. Les speeds tests sont parfaits.
Pour le test -n 4 :
C:\>nspeed.exe -cpu get -n 4 http://bouygues.testdebit.info/10G/10G.iso
Jobs:
0 HTTP client {Method: GET, URL: "http://bouygues.testdebit.info/10G/10G.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Method: GET, URL: "http://bouygues.testdebit.info/10G/10G.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
2 HTTP client {Method: GET, URL: "http://bouygues.testdebit.info/10G/10G.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
3 HTTP client {Method: GET, URL: "http://bouygues.testdebit.info/10G/10G.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
11:39AM | 65| 62| 55| 66|, active jobs: 0 / active goroutines: 16
11:39AM | 59| 66| 62| 61|, active jobs: 0 / active goroutines: 16
11:39AM | 63| 62| 62| 53|, active jobs: 0 / active goroutines: 16
11:39AM | 54| 53| 58| 54|, active jobs: 0 / active goroutines: 16
11:39AM | 44| 54| 53| 51|, active jobs: 0 / active goroutines: 16
11:39AM | 70| 74| 64| 62|, active jobs: 0 / active goroutines: 16
11:39AM | 55| 55| 50| 45|, active jobs: 0 / active goroutines: 16
11:39AM | 65| 57| 52| 54|, active jobs: 0 / active goroutines: 16
11:39AM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 41.9 Mbps| 0 bps| 8.00| 42.0 MB| 0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 16.718 ms)
Job 1| 42.1 Mbps| 0 bps| 8.00| 42.1 MB| 0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 15.324 ms)
Job 2| 42.3 Mbps| 0 bps| 8.00| 42.3 MB| 0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 15.324 ms)
Job 3| 42.1 Mbps| 0 bps| 8.00| 42.1 MB| 0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 14.757 ms)
Total| 168.4 Mbps| 0 bps| 8.00| 168.4 MB| 0 B|
-
Get-NetAdapterHardwareInfo ca donne quoi ?
Apres ca ressemble a un probleme d'antivirus ou autre truc qui analyse et limite le trafic par session. bien le cpu ne soit pas a 100% il est trop haut pour du 40Mbps x 4.
c'est quoi comme PC ?
-
C'est un 4coeurs ryzen, j'avais surement d'autres applications ouvertes.
Sans être du métier, je m'y connais tout de même un minimum et après plusieurs tests, je peux affirmer que celà ne vient pas du PC ou de la ligne internet PC ---> livebox.
Je rappelle aussi que le problème est toujours là avec linux, ainsi que sur un autre PC en ethernet, voir même en wifi (en étant à côté de la box).
aucunes saturations du CPU lors des speedstests qui sont parfait : 400M/400M.
C'est pour celà que je suspect un problème du côté de la livebox3 oubien du boitier ONT, un peu le même problème que chez free?
-
C'est un 4coeurs ryzen, j'avais surement d'autres applications ouvertes.
Sans être du métier, je m'y connais tout de même un minimum et après plusieurs tests, je peux affirmer que celà ne vient pas du PC ou de la ligne internet PC ---> livebox.
Je rappelle aussi que le problème est toujours là avec linux, ainsi que sur un autre PC en ethernet, voir même en wifi (en étant à côté de la box).
aucunes saturations du CPU lors des speedstests qui sont parfait : 400M/400M.
C'est pour celà que je suspect un problème du côté de la livebox3 oubien du boitier ONT, un peu le même problème que chez free?
Chez Free, c'est un ONU, qui "convertit" le 10G-EPON SFP+ fibre en une interface SFP 1Gb sur laquelle est connecté un DAC de quelques centimètres qui lui est connecté à l'entrée SFP 1G de la Box.
L'ONT, a d'un côté la fibre, et de l'autre côté une interface RJ45 1Gb...
Pour ma part, je pencherais pour une mise à jour "malheureuse", soit de la box, soit de l'ONT...
Mais il serait "curieux" qu'Orange ait suivi Free sur le chemin de la "bourde" des ONU V2 Free...
Free a pas mal joué les précurseurs, mais de là à penser qu'Orange a "copié", faut quand même pas abuser! ;)
-
C'est un 4coeurs ryzen, j'avais surement d'autres applications ouvertes.
Sans être du métier, je m'y connais tout de même un minimum et après plusieurs tests, je peux affirmer que celà ne vient pas du PC ou de la ligne internet PC ---> livebox.
Je rappelle aussi que le problème est toujours là avec linux, ainsi que sur un autre PC en ethernet, voir même en wifi (en étant à côté de la box).
aucunes saturations du CPU lors des speedstests qui sont parfait : 400M/400M.
C'est pour celà que je suspect un problème du côté de la livebox3 oubien du boitier ONT, un peu le même problème que chez free?
11:39AM | 65| 62| 55| 66|, active jobs: 0 / active goroutines: 16
11:39AM | 59| 66| 62| 61|, active jobs: 0 / active goroutines: 16
11:39AM | 63| 62| 62| 53|, active jobs: 0 / active goroutines: 16
11:39AM | 54| 53| 58| 54|, active jobs: 0 / active goroutines: 16
11:39AM | 44| 54| 53| 51|, active jobs: 0 / active goroutines: 16
11:39AM | 70| 74| 64| 62|, active jobs: 0 / active goroutines: 16
11:39AM | 55| 55| 50| 45|, active jobs: 0 / active goroutines: 16
11:39AM | 65| 57| 52| 54|, active jobs: 0 / active goroutines: 16
Les colonnes de 4 chiffres affichées par NSpeed sont le taux d'occupation en % des coeurs du cpu pendant le test, les valeurs vont de 0 a 100%.
On constate que les 4 coeurs sont en moyenne plus de 60% pendant le test.
Ceci pour un débit de 4 x 40Mbps environ.
Ca n'exclu pas qu'il peut y avoir un souci en dehors du PC mais 60% ou plus par cœur pour du 40 Mbps par cœur indique clairement un souci dans le PC quand meme ...
Je ne vois ce qui dans la box ou l'ONT pourrait expliquer ce qui se passe dans le PC. Meme si je n'exclu, par ailleurs, un souci dans la box ou l'ONT
-
un article ici : https://www.clubic.com/connexion-internet/fai-orange-livebox/actualite-525279-orange-livebox-3.html
indique ce qui suit :
la LiveBox Play embarque un processeur Fusiv Vox185 d'Ikanos, et peut gérer la fibre jusqu'à 200 Mb/s,
notez le jusqu'à, alors est-ce que 200Mbps faisait référence à la capacité du SOC, ou à l'offre commerciale de l'époque ?
https://deviwiki.com/wiki/Sagemcom_Livebox_3
1 coeur a 500Mhz ::)
La Livebox 4, avec un dual core ARM 1Ghz (Broadcom 63138) est largement plus efficace et tien le Gbit sur le WAN, j'ai 2 routeurs sous OpenWRT avec ce SOC donc je peux le confirmer.
Ca n'explique peut etre pas ce qu'il se passe sur le PC, m'enfin voilà quoi...si déjà le SOC est pas prévu pour encaisser plus de 200Mbps...
-
un article ici : https://www.clubic.com/connexion-internet/fai-orange-livebox/actualite-525279-orange-livebox-3.html
indique ce qui suit :notez le jusqu'à, alors est-ce que 200Mbps faisait référence à la capacité du SOC, ou à l'offre commerciale de l'époque ?
https://deviwiki.com/wiki/Sagemcom_Livebox_3
1 coeur a 500Mhz ::)
La Livebox 4, avec un dual core ARM 1Ghz (Broadcom 63138) est largement plus efficace et tien le Gbit sur le WAN, j'ai 2 routeurs sous OpenWRT avec ce SOC donc je peux le confirmer.
Ca n'explique peut etre pas ce qu'il se passe sur le PC, m'enfin voilà quoi...si déjà le SOC est pas prévu pour encaisser plus de 200Mbps...
Sans être du métier, je m'y connais tout de même un minimum et après plusieurs tests, je peux affirmer que celà ne vient pas du PC ou de la ligne internet PC ---> livebox.
Ensuite, as-tu la possibilité de faire le test avec la même machine sur une autre connexion fibre Orange ?
Je pose ça là comme ça une dernière fois, maintenant je :-X
-
D'après ce qu'a affirmé l'auteur dans son premier post, le problème est depuis le début du raccordement à la fibre avec cette fameuse Livebox 3...
Par ailleurs, l'auteur a indiqué que lors du dernier test, il y avait d'autres choses qui tournaient sur la machine en question...
Les conditions de ce test impliquent des résultats non significatifs.
J'ai la faiblesse de penser que le rédacteur du topic original ne nous balade pas, mais qu'il part d'un postulat "bloquant" qui consiste à partir du principe que le problème ne peut pas être autre chose que sur le matériel de l'opérateur... Regrettable! En ayant été responsable d'exploit informatique (j'ai "un peu" vécu!), j'ai appris qu'il faut TOUJOURS tout envisager, même la poutre dans son propre œil!
Ce que je n'ai pas bien "vu" non plus est la présence ou non d'un routeur ou d'un switch actif entre la box et les bécanes...
Toutefois, en relisant le topic, il a été dit que le problème se posait avec différentes machines, sous différents systèmes...
Par cette affirmation, on peut envisager (hormis la présence de matos entre la box et les appareils "testeurs") que le problème serait "ailleurs".
La question à se poser est: Est-ce que d'autres "heureux possesseurs" de Livebox 3 étant fibrés ont ce problème, à condition qu'ils l'aient détecté!
A ce moment, on pourrait peut-être avancer que le problème serait sur la box...
Bonne journée à toutes et à tous!
-
100 Mbps par session comme indiqué dans son premier post est plausible si la box est une quad-core et limite a 100 Mbps par core.
D'ou d'ailleurs les offres sont limitées a 400 Mbps sur cette LB3.
mais ca n'explique pas pour autant 40 Mbps par session sur son PC avec 60% de cpu.
Apres 100 Mbps par session pour une LB3 , c'est fort plausible.
-
Euh en général ce genre de CPU ne gère rien en soft. Tout est fait avec du hardware.
On peut très bien avoir un CPU à 100MHz, et faire du routage à 1Gbps hein ! C'est juste que le CPU ne verra aucun paquet, il est là juste pour gérer le serveur HTTP et envoyer les ordres au firmware des DSP/accelérateurs HW pour tout ce qui est relatif au routage/NAT/masquerading.
En simple exemple, j'ai un routeur belkin avec un CPU à 300MHz => avec le firmware d'origine et ses drivers prioritaires gérant l'accélération HW => routage LAN/WAN avec masquerading et mini firewall => 800Mbps. Même routeur sous openWRT avec des drivers libres et pas d'utilisation d'accélérateurs HW (car code proprio) => même routage => 200Mbps max (peut importe le nombre de connexions).
mais ca n'explique pas pour autant 40 Mbps par session sur son PC avec 60% de cpu.
+1
-
Euh en général ce genre de CPU ne gère rien en soft. Tout est fait avec du hardware.
On peut très bien avoir un CPU à 100MHz, et faire du routage à 1Gbps hein ! C'est juste que le CPU ne verra aucun paquet, il est là juste pour gérer le serveur HTTP et envoyer les ordres au firmware des DSP/accelérateurs HW pour tout ce qui est relatif au routage/NAT/masquerading.
En simple exemple, j'ai un routeur belkin avec un CPU à 300MHz => avec le firmware d'origine et ses drivers prioritaires gérant l'accélération HW => routage LAN/WAN avec masquerading et mini firewall => 800Mbps. Même routeur sous openWRT avec des drivers libres et pas d'utilisation d'accélérateurs HW (car code proprio) => même routage => 200Mbps max (peut importe le nombre de connexions).
+1
Effectivement,
la LB3 semble avoir un ASIC en charge de l'hardware offload, la Atheros AR8327 (https://lafibre.info/images/doc/201106_spec_AR8327.pdf)
Cet ASIC semble être relié aux 4 ports LAN, au port WAN et au CPU : https://www.electronest.fr/demonter/informatique/orange_livebox3/ (https://www.electronest.fr/demonter/informatique/orange_livebox3/)
Cependant si un scénario n'est pas géré par l'ASIC, le trafic peut passer par le CPU, et limiter les performances. Ça reste donc une piste à mon avis.
-
Effectivement,
la LB3 semble avoir un ASIC en charge de l'hardware offload, la Atheros AR8327 (https://lafibre.info/images/doc/201106_spec_AR8327.pdf)
Cet ASIC semble être relié aux 4 ports LAN, au port WAN et au CPU : https://www.electronest.fr/demonter/informatique/orange_livebox3/ (https://www.electronest.fr/demonter/informatique/orange_livebox3/)
Cependant si un scénario n'est pas géré par l'ASIC, le trafic peut passer par le CPU, et limiter les performances. Ça reste donc une piste à mon avis.
Je me risque: Par exemple la gestion d'un parefeu même basique en IPV6?
-
Effectivement,
la LB3 semble avoir un ASIC en charge de l'hardware offload, la Atheros AR8327 (https://lafibre.info/images/doc/201106_spec_AR8327.pdf)
Cet ASIC semble être relié aux 4 ports LAN, au port WAN et au CPU : https://www.electronest.fr/demonter/informatique/orange_livebox3/ (https://www.electronest.fr/demonter/informatique/orange_livebox3/)
Cependant si un scénario n'est pas géré par l'ASIC, le trafic peut passer par le CPU, et limiter les performances. Ça reste donc une piste à mon avis.
Je ne dis pas ce que tu écris est faux, cependant pour mon cas le CPU n'est jamais saturé lors de la limitation du débit.
-
* le CPU de la box ;)
-
D'ou d'ailleurs les offres sont limitées a 400 Mbps sur cette LB3.
à l'époque où la livebox 4 n'existait pas encore, Orange vendait son offre Livebox Jet avec cette box, 500/200, avec en pratique 1000/200.
Les utilisateurs ne rencontraient pas les problèmes évoqués sur ce thread.
-
Une époque sans IPv6, en PPPoE, avec des protocoles de version inférieur.
C'est comme mon ordi, j'ai un CPU Intel de 5ème génération, je dois forcer le h264 sur YouTube (en utilisant Safari) car en VP9 le flux n'est pas offloadé donc 100% du CPU et 30 minutes d'autonomie. Avec le h264 aucun soucis, 10% de CPU offloadé et autonomie 10 heures...
-
Une époque sans IPv6, en PPPoE, avec des protocoles de version inférieur.
le DHCP et l'IPv6 est quand même arrivé au printemps 2016 chez Orange. La livebox 4 est sortie à la fin du printemps. Donc pendant plusieurs semaines minimum les offres ont été vendu avec la livebox 3 et IPv6 + DHCP. Je suis quasi sur qu'avant la sortie de la livebox 4 il existait une offre Jet 500 Mbit/s qui permettait déjà le 1 Gbit/s
Je me souviens que sur mon abonnement Fibre 300 Mbit/s j'avais bien le débit souscrit avec la LB3 et IPV6.
-
Il se peut qu'une mise à jour ai changé le fonctionnement par rapport à avant, des choix techniques, etc
Y'a deux tests à faire :
- choper une LB4/LB5 et la coller sur sa ligne pour écarter ou pas un soucis de LB3
- déplacer la machine de test sur une autre fibre, de préférence Orange pour la précision du diag (amis / famille / voisin / travail), y'a forcément une possibilité, pour écarter ou pas un soucis spécifiquement à son domicile
-
le DHCP et l'IPv6 est quand même arrivé au printemps 2016 chez Orange. La livebox 4 est sortie à la fin du printemps. Donc pendant plusieurs semaines minimum les offres ont été vendu avec la livebox 3 et IPv6 + DHCP. Je suis quasi sur qu'avant la sortie de la livebox 4 il existait une offre Jet 500 Mbit/s qui permettait déjà le 1 Gbit/s
Je me souviens que sur mon abonnement Fibre 300 Mbit/s j'avais bien le débit souscrit avec la LB3 et IPV6.
En effet, sans compter les nombreux abonnés qui n'ont pas été migrés immédiatement en livebox 4 (et qui sont encore en lb3 aujourd'hui)
-
En effet, sans compter les nombreux abonnés qui n'ont pas été migrés immédiatement en livebox 4 (et qui sont encore en lb3 aujourd'hui)
99% de Michu
-
Il se peut qu'une mise à jour ai changé le fonctionnement par rapport à avant, des choix techniques, etc
Y'a deux tests à faire :
- choper une LB4/LB5 et la coller sur sa ligne pour écarter ou pas un soucis de LB3
- déplacer la machine de test sur une autre fibre, de préférence Orange pour la précision du diag (amis / famille / voisin / travail), y'a forcément une possibilité, pour écarter ou pas un soucis spécifiquement à son domicile
Je viens de changer de Livebox5 et bien rien n'a changé...les tests restent les même, toujours un bridage entre 0.7mo/s et 5mo/s qui dépendent des sites.
Visiblement celà ne venait pas de la livebox3 et son ONT externe...
D'un point de vue technique, ce bridage est pour moi hors du commun.
J'ai deux PC avec windows10 et linux chacun, et çà me le fait pareil sur les deux PC et système d'exploitation (bridage des download, avec en contradiction des speedtests parfait ).
Rien entre la livebox, rien qu'un câble de 1mètre cat6et l'autre 15mètres cat6.
Je n'ai peut-être pas de chance, peut-être que les deux PC ont un problème de drivers ?
J'ai pensé à une alternative, c'est à dire une optimisation (au lieu d'un bridage)de l'arbre Gpon chez Orange, mais bon celà le fait à tout heure.
:'(
-
Maintenant qu'on a isolé la LB, je t'invite à faire tes tests avec le même matériel sur une autre connexion fibre.
-
Je n'ai peut-être pas de chance, peut-être que les deux PC ont un problème de drivers ?
comme demandé 3 fois déja: ;D
que donne "Get-NetAdapterHardwareInfo" (sous powershell) ?
-
Bon et bien je pense avoir au moins résolu le problème. Mais la "source" même de ce bridage je ne peux pas le justifier clairement.
Cet après-midi en ayant remplacé la nouvelle livebox5 en faisant les tests de download seulement sous windows10, j'étais un peu trop hâtif.
Voici les constats et la maintenance par ordre :
1) j'ai branché la livebox5, je constate par "désespoir" que les débits sur le PC N°1, notamment avec le fichier que vous m'avez conseillé : http://bouygues.testdebit.info/10G/10G.iso, et pleins d'autres, que les download sont bridés par le même débit que avant avec la Livebox3 c'est à dire entre 0.7mo/s et 5mo/s.
2) Ce soir je décide de faire le test sur l'autre PC N°2 avec linux, et là aucun problème. Curieux.
3) Je passe avec le PC N°2 sous windows10, et à nouveau ce bridage. Vous me direz que c'était windows10 le problème ? Mais non, avant avec la LB3 avec linux le bridage était présent !!!
4)Vu les problèmes avec la LB3,j'ai donc trifouillé aux débuts quelques options dans les paramètres réseaux, notamment : https://www.papergeek.fr/windows-10-bride-votre-connexion-internet-voici-comment-len-empecher-6333 avec la commande bien connue : netsh int tcp set global autotuninglevel=disabled.
5)Je remets donc la valeur par défaut sur les deux PC: netsh int tcp set global autotuninglevel=normal
Et là effectivement le problème est résolu, je suis constamment à 50mo/s sous windows10 mais aussi sous linux (dont je n'ai fait aucun changement dans les options). Bon c'est contradictoire, car on conseille de déactiver cette option pour que windows ne bride pas la connection.
6) Constat à noter : je décide de refaire les tests avec la livebox3, cependant le réseau orange ne voulait plus s'y connecter. Y-a-t-il un robot qui détecte les numéros de des abonnés, afin d'éviter les échange de box ??
Conclusion : je rectifie ce que j'ai écris cet après-midi, je pense que la livebox3 ou son ONT était à l'origine du problème. Soit un conflit logiciel, un bug logiciel interne. Pendant des semaines j'ai recherché sous windows ou linux ce qui pourrait faire bugguer, et là en une soirée j'ai résolu le problème.
-
Constat à noter : je décide de refaire les tests avec la livebox3, cependant le réseau orange ne voulait plus s'y connecter. Y-a-t-il un robot qui détecte les numéros de des abonnés, afin d'éviter les échange de box ??
Quand tu changes de box, tu obtiens un nouveau numéro de série en rapport avec l'ONT. Il faut renseigner ce numéro dans l'OLT pour l'authentification. Il est normal que tu ne puisses pas changer comme tu veux.
-
Bonjour,
Excuses moi de déterrer un peu ce sujet , j'ai toujours des problèmes de débit (uniquement en upload et en ipv6 bridé autours de 100mb/s) avec mon offre sosh (LB3 et ONT Huawei) . A l’époque j'avais identifié le probleme sur l'offload tcp qui n'etait pas gérer pareil en IPV4 et IPV6 et qui faisait surement intervenir le soc ikanos en cpu.
Peux tu me confirmer qu'avec une livebox5 tu n'as plus ces problèmes ?
Bon et bien je pense avoir au moins résolu le problème. Mais la "source" même de ce bridage je ne peux pas le justifier clairement.
Cet après-midi en ayant remplacé la nouvelle livebox5 en faisant les tests de download seulement sous windows10, j'étais un peu trop hâtif.
Voici les constats et la maintenance par ordre :
1) j'ai branché la livebox5, je constate par "désespoir" que les débits sur le PC N°1, notamment avec le fichier que vous m'avez conseillé : http://bouygues.testdebit.info/10G/10G.iso, et pleins d'autres, que les download sont bridés par le même débit que avant avec la Livebox3 c'est à dire entre 0.7mo/s et 5mo/s.
2) Ce soir je décide de faire le test sur l'autre PC N°2 avec linux, et là aucun problème. Curieux.
3) Je passe avec le PC N°2 sous windows10, et à nouveau ce bridage. Vous me direz que c'était windows10 le problème ? Mais non, avant avec la LB3 avec linux le bridage était présent !!!
4)Vu les problèmes avec la LB3,j'ai donc trifouillé aux débuts quelques options dans les paramètres réseaux, notamment : https://www.papergeek.fr/windows-10-bride-votre-connexion-internet-voici-comment-len-empecher-6333 avec la commande bien connue : netsh int tcp set global autotuninglevel=disabled.
5)Je remets donc la valeur par défaut sur les deux PC: netsh int tcp set global autotuninglevel=normal
Et là effectivement le problème est résolu, je suis constamment à 50mo/s sous windows10 mais aussi sous linux (dont je n'ai fait aucun changement dans les options). Bon c'est contradictoire, car on conseille de déactiver cette option pour que windows ne bride pas la connection.
6) Constat à noter : je décide de refaire les tests avec la livebox3, cependant le réseau orange ne voulait plus s'y connecter. Y-a-t-il un robot qui détecte les numéros de des abonnés, afin d'éviter les échange de box ??
Conclusion : je rectifie ce que j'ai écris cet après-midi, je pense que la livebox3 ou son ONT était à l'origine du problème. Soit un conflit logiciel, un bug logiciel interne. Pendant des semaines j'ai recherché sous windows ou linux ce qui pourrait faire bugguer, et là en une soirée j'ai résolu le problème.
-
Bonjour,
Excuses moi de déterrer un peu ce sujet , j'ai toujours des problèmes de débit (uniquement en upload et en ipv6 bridé autours de 100mb/s) avec mon offre sosh (LB3 et ONT Huawei) . A l’époque j'avais identifié le probleme sur l'offload tcp qui n'etait pas gérer pareil en IPV4 et IPV6 et qui faisait surement intervenir le soc ikanos en cpu.
Peux tu me confirmer qu'avec une livebox5 tu n'as plus ces problèmes ?
J'avais aussi une LB3 et un ONT Huawei , Je confirme que le problème était résolu avec la livebox5.
Cependant les options sous windows10 peuvent aussi jouer un rôle par-dessus, avec la LB5 j'étais aussi bridé voir les points 4 et 5.
-
Merci.
Oui j'ai vu ces manipulations de la pile windows tcp/ip qui sont impactées en fonction du RTT : https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html