La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => K-Net => Opérateurs grand public alternatifs => Espace technique internet K-Net => Discussion démarrée par: Thibault le 05 octobre 2013 à 13:26:21
-
Je sais pas si il y a un rapport, mais le débit en téléchargement (de testdebit.info) depuis wget (pc windows), idem sur rpi, idem avec Chrome sous Windows est très bas, il commence à 2 mo/s et en 2-3 sec il tombe < 1mo/s. Vous avez une idée ? Sachant que le test avec le script sur testdebit.info marche très bien.
pi@raspberrypi ~ $ wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
--2013-10-05 13:22:53-- http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
Résolution de testdebit.info (testdebit.info)... 89.84.127.54
Connexion vers testdebit.info (testdebit.info)|89.84.127.54|: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»
1% [ ] 6 276 275 638K/s eta 10m 24s
Les autres téléchargements vont très vites : origin / steam / debit.k-net.fr ....
J'avais déjà vu ce bug il y a quelques temps. Mais je suis sûr qu'au début que j'étais chez k-net il n'y avais pas ce problème.
EDIT : IDEM en FTP.
-
Ce n'est pas le serveur car des abonnés Free FTTH ont des très bon débits sur ce serveur :
$ wget -O /dev/null https://testdebit.info:81/fichiers/500Mo.dat (https://testdebit.info:81/fichiers/500Mo.dat)
--2013-10-05 13:03:40-- https://testdebit.info:81/fichiers/500Mo.dat (https://testdebit.info:81/fichiers/500Mo.dat)
Resolving testdebit.info (testdebit.info)... 89.84.127.54
Connecting to testdebit.info (testdebit.info)|89.84.127.54|:81... connected.
HTTP request sent, awaiting response... 200 OK
Length: 500000000 (477M) [application/x-ns-proxy-autoconfig]
Saving to: `/dev/null'
100%[==============================================================================================================================================================>] 500,000,000 106M/s in 4.6s
2013-10-05 13:03:45 (103 MB/s) - `/dev/null' saved [500000000/500000000]
Voici le traceroute depuis lafibre.info /adeli :
$ mtr -rwc100 81.28.200.xxx
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.3 4.2 0.2 71.3 10.8
2.|-- kwaoo.peers.lyonix.net 0.0% 100 3.2 3.3 3.1 4.0 0.2
3.|-- border1-sgp.kwaoo.net 2.0% 100 3.4 3.6 3.3 5.3 0.4
4.|-- xxx-200-28-81.ftth.cust.kwaoo.net 2.0% 100 6.7 6.7 6.4 8.1 0.3
Voici le traceroute depuis testdebit.info / Bouygues Telecom :
$ mtr -rwc100 81.28.200.xxx
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.3 0.3 0.2 0.7 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 3.0% 100 7.5 9.4 0.2 217.1 35.0
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 51.2 13.0 0.4 95.6 23.5
4.|-- be35.cbr01-ntr.net.bbox.fr 0.0% 100 8.0 4.9 1.1 8.7 2.3
5.|-- lag13.rpt02-ix2.net.bbox.fr 84.0% 100 2.0 2.1 1.8 3.6 0.5
6.|-- 83.167.32.213.static.not.updated.neotelecoms.com 0.0% 100 1.8 2.1 1.7 35.1 3.4
7.|-- 83.167.55.46 0.0% 100 1.9 2.1 1.9 13.4 1.2
8.|-- xe2-1-0.ter1.eqx2.par.as8218.eu 0.0% 100 2.0 2.8 1.9 48.6 5.3
9.|-- ge1-5.br1.rdb.par.ielo.net 0.0% 100 2.5 4.6 2.1 14.8 3.4
10.|-- 10ge-5-2-cr2.th2.fr.rt.ielo.net 0.0% 100 11.5 3.6 1.3 11.5 3.3
11.|-- 2ge-e1-17-e1-18-cr5.le9-lyon.fr.rt.ielo.net 0.0% 100 8.4 10.6 8.4 19.2 3.4
12.|-- kwaoo.ix-customers-le9lyon.ielo.net 0.0% 100 9.0 9.1 8.8 11.1 0.4
13.|-- border1-sgp.kwaoo.net 3.0% 100 12.2 12.2 11.6 16.1 0.7
14.|-- xxx-200-28-81.ftth.cust.kwaoo.net 2.0% 100 14.7 15.2 14.5 17.8 0.6
Je pense que le pb viens des de la saturation du routeur de SGP, mais j’aimerais bien savoir comment cela se comporte en situation dégradée en fonction des noyaux linux sur les serveurs.
Tu pourrais tester les autres serveurs ?
Serveur 1 (config défaut) : wget -O /dev/null http://1.testdebit.info/fichiers/500Mo.dat (http://1.testdebit.info/fichiers/500Mo.dat)
Serveur 2 (tso/gso off) : wget -O /dev/null http://2.testdebit.info/fichiers/500Mo.dat (http://2.testdebit.info/fichiers/500Mo.dat)
Serveur 3 (tso/gso off) : wget -O /dev/null http://3.testdebit.info/fichiers/500Mo.dat (http://3.testdebit.info/fichiers/500Mo.dat)
Serveur 4 (vieux linux) : wget -O /dev/null http://bouygues.testdebit.info/fichiers/500Mo.dat (http://bouygues.testdebit.info/fichiers/500Mo.dat)
-
Non ce n'est pas une saturation, car le test de testdebit.info marche parfaitement.
Et à toute heure, le débit pour les téléchargements ne sont pas "hauts". Par contre l'upload marche très bien !
-
Je veux bien un comparatif des débits avec les 4 serveurs pour voir si c'est bien le tso/gso off qui arrive en première position.
Le SpeedTest contourne les saturations en démarrant de nombreuses connexions en parallèle, ce qui permet de remplir les tuyaux même si certaines connexions TCP ont le débit qui chute avec des pertes de paquets
Le problème devrait être identique avec les serveurs d'OVH : http://proof.ovh.net/files/ (http://proof.ovh.net/files/)
A noter que le samedi et le dimanche, la période de pointe démarre très tôt.
-
Sur les serveurs de OVH je suis à 3mo/s pour un fichier.
C'est ce que j'ai au début avec testdebit.info ensuite ça s'écroule.
Tu pourrais me mettre un gros fichier sur lafibre.info ?
EDIT : Ha oui Vivien tu as raison, à 1h du mat tout va bien ! Je te fais tes tests demain pendant une heure de pointe.
-
Si tu as un bon résultat avec OVH, tu devrait avoir un bon résultat avec les serveurs 2,3 et 4. Le serveurs d'OVH est proche du serveur 4.
N'hésites pas a remplacer 500Mo.dat dans mes liens par 1000Mo.dat pour avoir un fichier plus gros.
Sinon ,je te propose de mettre un script qui test chaque heure ton débit (avec des fichiers de 31mo, c'est normalement suffisant et cela évite de surcharger le réseau de K-Net)
Le script perl à télécharger pour ton petit linux : test_debit_ovh_bytel.pl (https://lafibre.info/testdebit/scripts/test_debit_ovh_bytel.pl)
Il faut le rendre exécutable : chmod +x test_debit_ovh_bytel.pl
rien de spécial à installer pour que le script fonctionne normalement.
Pour le démarrer le script a la main pour vérifier que tout est ok : ./test_debit_ovh_bytel.pl IPv4 n n n
Pour le démarrer toutes les heures et enregistrer les résultats, il faut le mettre dans la crontab :
crontab -e et rajouter à la fin :
10 * * * * ~/scripts/test_debit_full.pl IPv4 n n n >> ~/scripts/k-net.csv 2>> ~/scripts/k-net_err.txt
Là je pars du principe que le script est dans ton home dans le dossier scripts.
Un fichier .csv avec les résultats est crée et un fichier k-net_err.txt pour les éventuelles erreures (facultatif)
Bonus : si ta machine a un SmokePing, il est intéressant de l’arrêter afin de ne pas avoir le ping qui augmente. Le script a une option pour arrêter le smokeping au début des tests et le remettre quelques secondes après à la fin des tests :
10 * * * * ~/scripts/test_debit_full.pl IPv4 n n y >> ~/scripts/k-net.csv 2>> ~/scripts/k-net_err.txt
Pour que cela fonctionne, il faut donner le droit au scrip d'arreter smokeping et le démarrer sans avoir les droits root.
Pour cela tu dois taper $sudo visudo
Il suffit de rajouter dans à la fin du fichier après le #includedir :
titidu01 ALL=NOPASSWD: /usr/bin/service
il faut remplacer titidu01 par ton login (celui où le script perl est exécuté dans le crontab)
-
Ok je test ça, mais avec mon utilisation réseau le test peut ne pas être "propre".
Sinon tu peux pas me mettre un fichier aussi sur lafibre.info ?
Sur débit.k-net.fr je télécharge vite, mais je sais pas si c'est avant ou après l'élèment qui sature.
-
En cas de pertes de paquets le ping est très important et le ping vers lafibre.info et debit.k-net.fr est très faible donc ce n'est pas comparable. On peu avoir des bon débits en local même avec des pertes de paquets importantes.
Par contre OVH est très intéressant comme test.
-
Vivien j'ai besoin de ton aide (je suis encore débutant en linux) :
1) J'ai cette erreur mais ça fait quand même le test (5 fois par test, pour 5 téléchargement je suppose).
2) Sinon j'ai une session pi avec mot de passe et une session root avec aussi un mot de passe.
Smokeping est exécuté sur pi avec la commande 'sudo service smokeping start'
Donc j'ai pas trop compris ton histoire d'utilisateurs pour stopper Smokeping.
3) Faut que je démarre le script en mettant, la commande manuel que tu m'as donné pour lancer les cript, ça ne marche pas je dois marquer : "perl nomfichier", donc il y a une modification à faire pour qu'il comprenne que .pl correspond à perl ?
-
Le script ne demande pas d'être root.
J'ai oublié de te dire qu'il avait besoin de "curl" qui n'est peut-être pas installé par défaut avec ta distribution (il l'est avec Ubuntu server mais probablement pas avec Debian)
Pour l'installer : sudo apt install curl
-
Déjà installé :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
curl est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Vous avez du nouveau courrier dans /var/mail/root
-
Ça donne quoi quand tu exécute le test a la main ?
./test_debit_ovh_bytel.pl IPv4 n n n
Copie / colle le résultat dans une balise code.
-
C'est pas génant juste la variable $remote_ip :
pi@raspberrypi ~/script $ ./test_debit_ovh_bytel.pl IPv4 n n n
curl: unknown --write-out variable: 'remote_ip'
Use of uninitialized value $remote_ip in concatenation (.) or string at ./test_debit_ovh_bytel.pl line 70.
06/10/2013;12;raspberrypi;OVH IPv4;20,513496;23;19;42;63;12,333;31,625365;
curl: unknown --write-out variable: 'remote_ip'
Use of uninitialized value $remote_ip in concatenation (.) or string at ./test_debit_ovh_bytel.pl line 70.
06/10/2013;12;raspberrypi;Bytel srv1;15,529144;11;16;27;47;16,292;31,625365;
curl: unknown --write-out variable: 'remote_ip'
Use of uninitialized value $remote_ip in concatenation (.) or string at ./test_debit_ovh_bytel.pl line 70.
06/10/2013;12;raspberrypi;Bytel srv2;18,540928;13;16;29;49;13,646;31,625365;
curl: unknown --write-out variable: 'remote_ip'
Use of uninitialized value $remote_ip in concatenation (.) or string at ./test_debit_ovh_bytel.pl line 70.
06/10/2013;12;raspberrypi;Bytel srv3;20,253648;11;17;28;48;12,492;31,625365;
curl: unknown --write-out variable: 'remote_ip'
Use of uninitialized value $remote_ip in concatenation (.) or string at ./test_debit_ovh_bytel.pl line 70.
06/10/2013;12;raspberrypi;Bytel srv4;17,2676;11;17;28;46;14,652;31,625365;
-
OK.
Ta version de curl est trop ancienne pour supporter 'remote_ip', il faut la version curl 7.29 et sup (livré dans Ubuntu server 13.04 et suivant)
Ce n'est pas important.
Remplace la ligne 33 :
@curl1 = `/usr/bin/curl -$serveur_proto -s -w %{speed_download}-%{time_namelookup}-%{time_connect}-%{time_starttransfer}-%{time_total}-%{size_download}-%{remote_ip} -o /dev/null "$serveur_url"`;
par : (On enlève : -%{remote_ip})
@curl1 = `/usr/bin/curl -$serveur_proto -s -w %{speed_download}-%{time_namelookup}-%{time_connect}-%{time_starttransfer}-%{time_total}-%{size_download} -o /dev/null "$serveur_url"`;
Et la ligne 65 :
my $remote_ip = $curl2[6];
par
my $remote_ip = "0";
-
Ok, mais je viens de voir que tu t'es trompé dans le crontab, tu as nommé le script test_debit_full.pl à la place de test_debit_ovh_bytel.pl
PS : J'installe Curl > 7.29, en faisant un make, j'espère que ça va aller.
EDIT : J'arrive pas à make, quand je fais un make install, il fait bien des choses sans erreurs (enfin j'en vois pas) mais après il n'est pas installé.
EDIT : C'est bon j'ai réussi sans le make, en bidouillant un peu :
pi@raspberrypi /usr/bin $ curl -V
curl 7.32.0 (armv6l-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
-
Bon voilà un début,
Au début quand ip = 0 c'est pendant mes tests de curl, ensuite au commencement des ip correctes c'est à dire à 15h40, je fais un test toutes les 30 minutes, un à 10 et un à 40.
D'après les smokeping on est en plein dans une saturation à partir de 17h.
Date;Heure;Client;Serveur;Debit Moyen;Temps DNS;Temps connect;Temps connect+DNS;Temps start transfer+DNS;Temps total;Taille;Remote IP
(http://puu.sh/4J9ie.png)
-
Il faut prendre une moyenne pour avoir une info utilisable.
OVH : 5,2 Mb/s
Bytel srv 1 : 5,5 Mb/s
Bytel srv 2 : 7,2 Mb/s
Bytel srv 3 : 6,2 Mb/s
Bytel srv 4 : 7,0 Mb/s
Donc cela conforte bien ce que je me disais : le meilleur serveur est bien un tso/gso off et Testdebit.info est ces serveurs sont au moins égal à OVH.
On manque de données pour avoir une info fiables. srv2 et 3 sont identiques et les résultats sont bien différents.
Je pense qu'avec plus de tests ils devraient se rapprocher.
Après avec plus de donnée, on pourra faire une variation horaire.
Sinon, pour K-Net, il arrive quand le nouveau routeur ?
Là, le routeur de SGP bloque toute la journée à 2,5 Gb/s de capacité de routage (le dimanche c'est le jour où le trafic est le plus intense, bien que la météo soit plutôt favorable. Quand il pleut le trafic internet augmente encore)
-
Le routeur est en place, il nous faut du temps pour le configurer et travailler le scénario de migration de la production.
On aimerait éviter de perdre le département de l'Ain pendant 35 minutes comme le 10.06.
-
Bonne nouvelle !
Hop, le nouveau routeur est en prod, avec une bonne dose d'abonnés (pas tous) dessus !
-
Oui depuis ce nouveau routeur, pas l'air d'avoir de montée et en plus le débit reste stable vers testdebit.info en téléchargement.
Alors j'ai arrêté le test, voilà le dernier tableau.
-
Ça m'fait plaisir ;D
D'après mes stats, nous sommes à 1.8Gb sur l'ancien et 800Mb sur le nouveau, soit 2.6Gb au total, il est 20h15
-
Les résultats hors saturation pour comparer les serveurs : (résultats satisfaisants pour un fichier de 31 Mo)
OVH : 61,7 Mb/s moyen (62,5 Mb/s médian)
Bytel srv 1 : 68,1 Mb/s moyen ( 67,8 Mb/s médian)
Bytel srv 2 : 75,2 Mb/s moyen ( 74,7 Mb/s médian)
Bytel srv 3 : 74,1 Mb/s moyen ( 75,1 Mb/s médian)
Bytel srv 4 : 61,1 Mb/s moyen ( 62,6 Mb/s médian)
Quand je disais que le serveur d'OVH étais proche de la configuration du serveur Bytel4 !
Si tu as un bon résultat avec OVH, tu devrait avoir un bon résultat avec les serveurs 2,3 et 4. Le serveurs d'OVH est proche du serveur 4.
-
Oui le ďébit est pas mauvais au début du téléchargement mais chute après quelques secondes.
-
Le débit chute avec des plus gros fichiers ?
Normalement plus le fichier est gros, plus il augmente, le slow start devenant négligeable !
Il y a des fichiers de toutes les tailles https://testdebit.info (https://testdebit.info)
N'hésites pas a poster un exemple ou le débit est plus faible que ces moyennes avec un fichier plus gros : c'est anormal.
-
Depuis la mise en place du nouveau routeur chez K-Net, j'obtiens :
Serveur 1 (config défaut) : 10,5MB/s
Serveur 2 (tso/gso off) : 11,2MB/s
Serveur 3 (tso/gso off) : 10,8MB/s
Serveur 4 (vieux linux) : 11,1MB/s
-
11,2 MB/s = 11,2 Mio/s = 11,2 * 8 * 1024 * 1024 / 1 000 000 = 93,95 Mb/s
Pour les fichiers quand windows parle de Mo ce sont des multiples de 1024
Quand on achéte un disque dur de 1 To, c'est 1 000 000 000 000 octets
Une carte réseau 100 Mb/s, c'est 100 000 000 bits
-
Une carte réseau 100 Mbps c'est pas 100 000 000 de bits Vivien ?
-
J'ai corrigé.
Il manquait deux 0 pour le 100 Mb/s et trois zeros pour le To.