La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Bouygues Telecom => 
Débit fibre Bouygues => Discussion démarrée par: sheepou le 07 juin 2013 à 18:00:30
-
Bonjour,
Est-ce normal que lorsque je fais le test avec une seul connexion avec IPERF, je ne monte qu'à 50M et à 100 Mb/s avec la somme des 5 connexions ?
merci !
-
C'est anormal : avec une connexion TCP tu devrais monter à 93 Mb/s une seule connexion TCP.
-
salut,
j'ai en fait le même problème que sheepou
-
Serait-il possible de faire ces tests Wget j'ai pris un fichier plus petit de 500 Mo mais par contre je veux bien le laisser aller jusqu’au bout ce qui permet d'avoir le débit moyen :
Serveur avec un noyau linux 3.8 :
- wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
Serveur avec un noyau linux 3.2 :
- wget -O /dev/null http://2.testdebit.info/fichiers/500Mo.dat (http://2.testdebit.info/fichiers/500Mo.dat)
Serveur avec un noyau linux 2.6.24 :
- wget -O /dev/null http://bouygues.testdebit.info/fichiers/500Mo.dat (http://bouygues.testdebit.info/fichiers/500Mo.dat)
-
salut,
voici tout les test demandé sous debian squeeze noyaux 2.6.32-5-amd64
Serveur avec un noyau 3.8 :
wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
100%[====================================================================================>] 500 000 000 4,56M/s ds 87s
2013-06-08 14:22:21 (5,49 MB/s) - «/dev/null» sauvegardé [500000000/500000000]
Serveur avec un noyau 3.2 :
wget -O /dev/null http://2.testdebit.info/fichiers/500Mo.dat (http://2.testdebit.info/fichiers/500Mo.dat)
100%[====================================================================================>] 500 000 000 5,12M/s ds 83s
2013-06-08 14:26:30 (5,72 MB/s) - «/dev/null» sauvegardé [500000000/500000000]
Serveur avec un noyau 2.6.24 :
wget -O /dev/null http://bouygues.testdebit.info/fichiers/500Mo.dat (http://bouygues.testdebit.info/fichiers/500Mo.dat)
100%[====================================================================================>] 500 000 000 9,46M/s ds 49s
2013-06-08 14:33:08 (9,77 MB/s) - «/dev/null» sauvegardé [500000000/500000000]
jerem
-
Noyau Linux 3.8 : 5,49 Mio/s
Noyau Linux 3.2 : 5,72 Mio/s
Noyau Linux 2.6.24 : 9,77 Mio/s
Ta connexion ne donne de bon débit qu'avec le vieux systèmes d’exploitation !
Ce phénomène se produit en cas de perte de paquets et d'un ping > 11ms
Le souci existait chez Orange FTTH (surtout visible pour les villes du surd de la France), mais il a été résolut :
Il ne s'agissait pas d'un changement de firmware sur l'ONT mais d'une modification de paramètres sur le BAS. Ça a été déployé partout, pour tout le monde, il n'y a donc rien à demander à la hotline.
Pour comprendre il me faut plus d'infos :
- Ta ville (ce phénomène nécessite un ping > 11ms)
- Ton ping vers testdebit.info : mtr -rwc100 testdebit.info
-
encore un problème avec un protocole réseau visiblement....
noyau linux (coté serveur) > au 2.6.24 = mauvais débit
-
salut vivien, ma ville c'est pau
voici le mtr :
mtr -rwc100 testdebit.info
HOST: routerLinux Loss% Snt Last Avg Best Wrst StDev
1. ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
2. 106.159.64.86.rev.sfr.net 1.0% 100 20.8 23.0 20.2 43.0 4.1
3. 105.159.64.86.rev.sfr.net 0.0% 100 19.6 22.3 19.5 96.9 11.0
4. 114.12.6.109.rev.sfr.net 0.0% 100 23.1 26.0 19.8 31.6 3.5
5. tenge1-3.core02-c.club-internet.fr 35.0% 100 19.8 31.7 19.6 193.5 35.4
6. ae10.tcore02-t2.net.bbox.fr 0.0% 100 20.2 32.6 20.0 90.5 20.5
7. po114.core03-t2.net.bbox.fr 0.0% 100 20.0 27.3 19.9 174.3 25.1
8. v113.tengec5-10g.c6k01-t2.club-internet.fr 0.0% 100 20.2 20.2 20.0 31.8 1.2
9. 89.84.127.55 0.0% 100 20.1 20.2 20.0 21.0 0.1
-
Ce qu'il serait intéressant c'est de savoir si des abonnés SFR (directement sur le réseau SFR) ont également ce type de problème. Pour vérifier, il faut rajouter de la latence à la main (on arrive très bien à simuler ce problème en rajoutant de la latence).
Tutoriel pour rajouter de la latence sous Linux (cela s'adresse à ceux qui sont en Île de France) => Tutoriel pour générer des pertes de paquets / latence / gigue avec NetEm (https://lafibre.info/tutoriels-linux/generer-des-pertes-de-paquets/)
Voici ce qu'on on obtient comme courbe quand on est impacté :
En vert pointillé le débit avec un vieux Linux ou avec une très veille carte réseau 100 Mb/s sur le serveur (TOE non pris en charge)
En vert fixe le débit avec un Linux récent (fonctions de TOE activées)
Quand je parle de carte réseau ancienne, c'est une carte réseau qui ne prend pas en charge TOE, un déchargement de TCP/IP réalisé par la carte réseau => TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU (https://lafibre.info/tutoriels-linux/tcp-offload-engine/)
(https://lafibre.info/testdebit/ubuntu/201306_debit_en_fonction_noyau_linux.png)
Je décris le graphe pour les non voyants :
Il y a deux courbes indiquant le débit moyen obtenu pour le téléchargement d'un fichier de 100 Mo en fonction du ping.
Avec un ping inférieur à 11ms, le débit est de 70 Mb/s quel que soit le serveur utilisé
Quand le ping passe de 11ms à 12ms, le débit est divisé par plus de moitié pour les linux récents avec ToE.
Ensuite quand le ping augmente, le débit diminue très lentement pour les serveurs anciens (sans ToE) et continue sa baisse pour les serveurs récents avec ToE.
Ping de 12ms => débit moyen de 69 Mb/s (ancien) 30 Mb/s (récent)
Ping de 30ms => débit moyen de 63 Mb/s (ancien) 15 Mb/s (récent)
Ping de 100ms => débit moyen de 61 Mb/s (ancien) 5 Mb/s (récent)
Orange, Numericable et Bouygues Telecom avaient ce type de problème de débit et l'ont corrigé.
Il me semblait que les tests fait à l'époque montrait que SFR avait des bon débits même avec un ping élevé.
Je me demande si le phénomène ne toucherait pas que les abonnés du Pau Broadband Country.
-
Edit vivien : message fusionné avec le post déjà ouvert
Hello,
Je suis limité à 50 Mega sur un test OVH: http://rbx.proof.ovh.net/files/10Gio.dat (http://rbx.proof.ovh.net/files/10Gio.dat)
même limite sur un serveur Online.net (free)
Mais je suis à 100 Mega sur un Speedtest (Paris - Massy).
Qu'en est-il pour vous ?
-
C'est pas "débit vers OVH & Online" que tu veux dire ?
Chez moi RAS vers OVH :
pi@raspberrypi ~ $ wget -O /dev/null http://rbx.proof.ovh.net/files/10Gio.dat (http://rbx.proof.ovh.net/files/10Gio.dat)
--2013-06-10 08:41:43-- http://rbx.proof.ovh.net/files/10Gio.dat (http://rbx.proof.ovh.net/files/10Gio.dat)
Resolving rbx.proof.ovh.net (rbx.proof.ovh.net)... 188.165.12.106, 2001:41d0:2:876a::1
Connecting to rbx.proof.ovh.net (rbx.proof.ovh.net)|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10737418240 (10G) [application/octet-stream]
Saving to: `/dev/null'
3% [> ] 392,230,496 11.2M/s eta 14m 49s ^C
Par contre j'ai cru comprendre qu'il pourrait y avoir une baisse de débit avec la hausse du ping depuis Pau, vivien en a parlé sur un autre sujet la semaine dernière.
-
Oui mais tu es sur Paris toi (d'après ton profil), donc tu comptes pas :)
Mon test proviens bien d'une ligne Pau. Je ne peux pas faire les tests wget donnés, je n'ai pas linux pour la commande... A moins que je peux le faire aussi sous windows en prenant le lien directement ? Ainsi que pour le ping testdebit.info ?
Quand je dis "depuis": c'est le serveur qui envoi les données. C'est une contradiction de dire "vers" car ca voudrait dire "envoi", donc "upload". Là il sagit bien de Download. :P
-
bonjour,
ras ici sur pau j'ai télécharger depuis ma debian sur mon serveur chez ovh
--2013-06-10 14:05:10-- http://91.121.96.xx/image.iso (http://91.121.96.xx/image.iso)
Connexion vers 91.121.96.xx:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Sauvegarde en : «/dev/null»
8% [======> ] 59 750 168 11,2M/s eta 57s
jerem
-
jeremyp3,
Le problème n'est pas présent sur les vieux Linux ne prenant pas en charge le déchargement des opérations TCP/IP sur la carte réseau appelé ToE.
Ce n'est pas présent non plus avec des veilles cartes Ethernet 100 Mb/s low cost. J'ai vu que certains serveurs dédies OVH avait ce type de carte Ethernet low-cost ou tout est fait par le processeur.
Serait-il possible de nous donner le retour de la commande : sudo ethtool -k eth0
Il est probable qu'il soit nécessaire d'installer ethtool : sudo apt install ethtool
Si la commande répond "off" systématiquement, c'est que tout est réalisé par le processeur, ce qui expliquerais les bon débits.
La question est pourquoi mettre TCP/IP sur les cartes réseau si cela entraîne de mauvaises performances ?
1/ Les mauvaises performances ne sont présentes qu'avec certains type de perte de paquets (donc il faudrait corriger ces pertes)
2/ Sans ToE avec des débits de 1 Gb/s la charge sur le processeur est importante.
Aujourd'hui la majorité des serveurs sur Internet décharge certaines opérations de TCP/IP à la carte réseau
=> TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU (https://lafibre.info/tutoriels-linux/tcp-offload-engine/)
-
Test depuis Paris avec +20ms :
pi@raspberrypi ~ $ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
--2013-06-10 12:06:54-- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
Resolving testdebit.info (testdebit.info)... 89.84.127.55
Connecting to testdebit.info (testdebit.info)|89.84.127.55|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-ns-proxy-autoconfig]
Saving to: `/dev/null'
100%[====================================>] 1,000,000,000 9.08M/s in 96s
2013-06-10 12:08:31 (9.89 MB/s) - `/dev/null' saved [1000000000/1000000000]
-
Sur mon serveur online.net limité à 50 Mbts:
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-unneeded: off [fixed]
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
-
C'est quoi le système d'exploitation ?
TITI, cela ressemble à du Linux très récent vu les options proposées.
Ubuntu 12.04 LTS ou la Debian 7 qui viens de sortir ne propose pas ces options.
Il faut Ubuntu 12.10 minimum pour avoir ces options.
J'ai oublié, jeremyp3 (et Titi) cela serait intéressant de connaître votre carte réseau : lspci | grep Ethernet
exemple avec un Serveur Power Edge R210 II que viens de me livrer Dell et que j'ai installé avec Ubuntu Server 12.04.2 avec Xen :
$ lspci | grep Ethernet
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
-
Noyau 3.8 :
pi@raspberrypi ~ $ wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
100%[======================================>] 500,000,000 10.4M/s in 46s
2013-06-10 12:30:36 (10.3 MB/s) - `/dev/null' saved [500000000/500000000]
Noyau 3.2 :
pi@raspberrypi ~ $ wget -O /dev/null http://2.testdebit.info/fichiers/500Mo.dat (http://2.testdebit.info/fichiers/500Mo.dat)
100%[======================================>] 500,000,000 11.2M/s in 45s
2013-06-10 12:33:28 (10.6 MB/s) - `/dev/null' saved [500000000/500000000]
Noyau 2.6.24 :
pi@raspberrypi ~ $ wget -O /dev/null http://bouygues.testdebit.info/fichiers/500Mo.dat (http://bouygues.testdebit.info/fichiers/500Mo.dat)
100%[======================================>] 500,000,000 10.4M/s in 49s
2013-06-10 12:34:34 (9.77 MB/s) - `/dev/null' saved [500000000/500000000]
-
C'est quoi le système d'exploitation ?
TITI, cela ressemble à du Linux très récent vu les options proposées.
Ubuntu 12.04 LTS ou la Debian 7 qui viens de sortir ne propose pas ces options.
Il faut Ubuntu 12.10 minimum pour avoir ces options.
Si c'est Debian 7
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
-
Merci pour l'info, j'avais testé Debian 7 bêta sur un serveur OVH (il était présent avant sa sortie) avec le kernel Debian et non le kernel OVH et il n'y avais pas ces options. Cela a été modifié les derniers mois avant la sortie donc.
-
Si je turn off et je donne au CPU le boulot, ca devrait corriger le problème? C'est "aussi" simple ?
Et pourquoi le problème est rencontré dans le sud et pas sur Paris ? Avec un test réalisé sur le meme serveur.
-
Les tests de Nico montrent que probablement seul Pau est touché (probablement un pb sur le réseau Axione ou sur la collecte du réseau par SFR qui entraîne des pertes de paquets)
Maintenant si ces pertes étaient nationales, Paris ne serait pas touché car le ping est plus faible et le phénomène se déclenche quand le ping atteint 12ms :
(https://lafibre.info/testdebit/ubuntu/201306_debit_en_fonction_noyau_linux.png)
Oui, c'est aussi simple que ca pour gagner du débit : tourne off tso et gso avec la commande suivante : sudo ethtool -K eth0 tso off gso off
Voici les tests effectués dans un le post de référence :
Désactiver ce qui fait chuter le débit avec "TCP ACK Supression" activé sur une box : ethtool -K eth0 tso off gso off
tcp-segmentation-offload et generic-segmentation-offload chacun séparèment ou activé tous les deux font chuter fortement le débit avec TCP ACK Supression.
Au contraire scatter-gather permet de gagner du débit avec "TCP ACK Supression" activé.
- TOE entièrement activé (défaut) : 3 min 13 secondes pour télécharger le fichier test
- TOE entièrement dés-activé : 56 secondes pour télécharger le fichier test
- Tout désactivé sauf tx-checksumming et scatter-gather : 33 secondes pour télécharger le fichier test
- Seul tcp-segmentation-offload et generic-segmentation-offload désactivé : 33 secondes pour télécharger le fichier test
-
Ok je vais faire les tests.
Mais ce problème n'est pas nouveau. Que fait axionne / SFR pour y remédier ?
-
Donc coté serveur ovh :
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Coté client :
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
jerem
-
jeremyp3, tso (tcp-segmentation-offload) et gso (generic-segmentation-offload) ne sont pas supportés (soit par la carte réseau, soit par le système d'exploitation). Il me semble que c'est un vieux linux coté serveur car peu d'option sont présentes avec ethtool.
=> Donc pas de bug possible
A noter que coté client peu importe les options, ce qui est important c'est coté serveur.
-
Je viens de test une fois les modif. faites (ethtool -K eth0 tso off gso off), et ca double en débit.
36 Mbts à 72 Mbts.
Ping de mon dédié vers mon IP: 21 ms. tout de même :o
-
J'ai fait une évolution sur testdebit.info
Chaque fichiers sont disponibles sur 3 serveurs :
Noyau Linux 3.8 (config par défaut) : http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
Noyau Linux 3.8 (tso/gso off) : http://2.testdebit.info/fichiers/500Mo.dat (http://2.testdebit.info/fichiers/500Mo.dat)
Linux 2.6.24 : http://bouygues.testdebit.info/fichiers/500Mo.dat (http://bouygues.testdebit.info/fichiers/500Mo.dat)
Serait-il possible a des abonnés SFR sur Pau de tester le débit sur les 3 serveurs ?
Voici ce que cela donne avec Bbox fibre sur le réseau Numericable : 11,2 Mio/s partout
$ wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat
2013-09-17 07:14:37 (11,2 MB/s) - «/dev/null» enregistré [500000000/500000000]
$ wget -O /dev/null http://2.testdebit.info/fichiers/500Mo.dat
2013-09-17 07:15:23 (11,2 MB/s) - «/dev/null» enregistré [500000000/500000000]
$ wget -O /dev/null http://bouygues.testdebit.info/fichiers/500Mo.dat
2013-09-17 07:16:13 (11,2 MB/s) - «/dev/null» enregistré [500000000/500000000]
-
le premier serveur
--2013-09-17 14:19:33-- http://1.testdebit.info/fichiers/500Mo.dat
Résolution de testdebit.info... 89.84.127.55
Connexion vers testdebit.info|89.84.127.55|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 500000000 (477M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
45% [======================================> ] 229 866 792 4,73M/s eta 48s
le second serveur
--2013-09-17 14:21:50-- http://2.testdebit.info/fichiers/500Mo.dat
Résolution de 2.testdebit.info... 89.84.127.49
Connexion vers 2.testdebit.info|89.84.127.49|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 500000000 (477M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
49% [========================================> ] 246 559 336 11,2M/s eta 24s
et le troisième
--2013-09-17 14:23:16-- http://bouygues.testdebit.info/fichiers/500Mo.dat
Résolution de bouygues.testdebit.info... 194.158.102.114
Connexion vers bouygues.testdebit.info|194.158.102.114|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 500000000 (477M) [chemical/x-mopac-input]
Sauvegarde en : «/dev/null»
64% [=====================================================> ] 321 661 315 10,1M/s eta 18s