Auteur Sujet: Bouygues Telecom sur le route serveur de FranceIX (Lu 10189 fois)

Boris de Bouygues Telecom · « **le:** 26 juillet 2012 à 13:32:20 »

Bonjour,

Bouygues Telecom vient de mettre en place un peering avec les "route serveur" de FranceIX et indirectement LyonIX.

Concrètement Bouygues Telecom Telecom peer avec tous ceux qui ont activé les "route serveur" même ceux qui n'ont pas fait de demande spécifique de Peering avec Bouygues Telecom.

K-Net fait parti des nouveaux peers de ce matin. Contrairement aux abonnés Kiwi fibre optique qui ont gagné 15,3ms le 23 juillet suite à la mise en place d'un peering sur Paris avec leur transitaire, ici aucun gain de ping n'est attendu car le chemin était déjà optimal (le peering avec le transitaire de K-Net se faisait sur France-IX). On passe par un routeur de moins soit un gain moyen de 0,1ms.
Cela fait un chemin de plus pour échanger le trafic entre Bouygues Telecom et K-Net. Il me semble que les abonnés K-Net on compris qu'il était important d'avoir plusieurs liens pour joindre une même destination.

Voici le traceroute vers k-net.fr en IPv4 depuis Paris / Telehouse2 :
Loss% Snt Last Avg Best Wrst StDev 1.|-- ae5.tcore02-t2.net.bbox.fr 0.0% 100 20.6 15.3 0.4 76.1 22.4 2.|-- la3.rpt01-th2.net.bbox.fr 40.0% 100 0.5 0.6 0.5 1.0 0.1 3.|-- 193.105.232.240 0.0% 100 7.5 7.6 7.4 16.6 0.9 4.|-- knet-xlrender.peers.lyonix.net 0.0% 100 7.6 7.7 7.6 8.1 0.1 5.|-- border1-sgp.kwaoo.net 0.0% 100 10.2 10.1 9.9 10.4 0.1 6.|-- admin-knet.kwaoo.net 0.0% 100 10.4 10.5 10.2 11.1 0.1

L'IPv6 sera probablement activé demain.

L'étape suivante est la venue de Bouygues Telecom sur LyonIX, ce qui permettra de joindre les abonnés de la région sans passer par Paris. Là le gain en ping sera important.

Cordialement,
Boris de Bouygues Telecom.

arnaud · « **Réponse #1 le:** 26 juillet 2012 à 20:47:15 »

Bonjour Boris,

Excellente nouvelle que voila.

Citation de: Boris de Bouygues Telecom le 26 juillet 2012 à 13:32:20

L'IPv6 sera probablement activé demain.

Et nous peerons avec le RS de Lyonix en IPV6 également.

Citer

L'étape suivante est la venue de Bouygues Telecom sur LyonIX, ce qui permettra de joindre les abonnés de la région sans passer par Paris. Là le gain en ping sera important.

K-Net utilise une politique de peering ouverte. Si vous acceptez le peering direct pour réduire l'AS PATH d'un AS, ce sera avec plaisir.

Boris de Bouygues Telecom · « **Réponse #2 le:** 27 juillet 2012 à 20:12:25 »

J'ai été un peu vite pour vous annoncer la bonne nouvelle. Nous allons couper le peering.

Le lien qui relie le LyonIX aux GIX parisiens n'est pas suffisamment dimensionné pour le trafic de Bouygues telecom. Ce soir on est limité a 2 Mo/s par connexion TCP soit 16 Mb/s.

Vous pouvez observer les mêmes limitations depuis le réseau K-Net en réalisant le téléchargement du fichier http://1.testdebit.info/fichiers/1000Mo.dat qui est hébergé par Bouygues Telecom.

$ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat --2012-07-27 19:49:02-- http://1.testdebit.info/fichiers/1000Mo.dat Résolution de testdebit.info (testdebit.info)... 89.84.127.55 Connexion vers testdebit.info (testdebit.info)|89.84.127.55|:80... connecté. requête HTTP transmise, en attente de la réponse... 200 OK Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig] Sauvegarde en : «/dev/null» 100%[======================================>] 125 000 000 2,00M/s ds 61s 2012-07-27 19:50:03 (1,96 MB/s) - «/dev/null» sauvegardé [125000000/125000000]

La coupure sera probablement effectuée lundi (pas de modification un vendredi soir).

Le peering sera remis en place une fois Bouygues Telecom présent directement sur le LyonIX.

Cordialement,
Boris de Bouygues Telecom.

PS: Traceroute ver le LyonIX :
$ mtr -4rwc100 www.lyonix.net HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev 1.|-- 89.84.127.61 0.0% 100 0.4 0.5 0.3 5.0 0.5 2.|-- V113.TenGEC5-10G.core04-t2.club-internet.fr 54.0% 100 0.3 4.3 0.3 95.3 15.8 3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 0.6 10.3 0.6 65.6 18.4 4.|-- po109.core02-c.net.bbox.fr 43.0% 100 0.9 9.4 0.8 122.1 25.6 5.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0 6.|-- ge0-1.sfr.c7301-1.ven01.phibee-telecom.net 0.0% 100 7.2 9.0 7.1 184.4 17.7 7.|-- c6506-1.ge3-13.ven01.phibee-telecom.net 0.0% 100 7.4 9.1 7.3 163.8 15.6 8.|-- c7301-1.ge0-0.ven01.phibee-telecom.net 0.0% 100 7.3 8.4 7.2 82.1 7.7 9.|-- transit-lyonix.phibee-telecom.net 0.0% 100 8.4 10.5 8.0 106.9 12.7 10.|-- lb.ix.lyonix.net 0.0% 100 8.4 8.0 7.8 8.5 0.1

arnaud · « **Réponse #3 le:** 27 juillet 2012 à 23:12:40 »

Citation de: Boris de Bouygues Telecom le 27 juillet 2012 à 20:12:25

J'ai été un peu vite pour vous annoncer la bonne nouvelle. Nous allons couper le peering.

Ca n'aura point duré longtemps

Citer

Le lien qui relie le LyonIX aux GIX parisiens n'est pas suffisamment dimensionné pour le trafic de Bouygues telecom. Ce soir on est limité a 2 Mo/s par connexion TCP soit 16 Mb/s.

effectivement :

Code: [Sélectionner]

wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2012-07-27 22:41:22--  http://1.testdebit.info/fichiers/1000Mo.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: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : Â«/dev/nullÂ»
100%[===============================================>] 125 000 000 2,17M/s   ds 63s

Citer

La coupure sera probablement effectuée lundi (pas de modification un vendredi soir).

En attendant, j'ai exclu nos annonces vers l'AS 5410 au travers du Route Server du Lyonix et baissé la préférence en sortie (lyonix) de façon à repasser le trafic par nos transits.
Cela semble être effectivement tout de suite mieux :

Code: [Sélectionner]

wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2012-07-27 22:48:01--  http://1.testdebit.info/fichiers/1000Mo.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: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»

100%[===============================================>] 125 000 000 29,2M/s   ds 4,2s    

2012-07-27 22:48:05 (28,4 MB/s) - «/dev/null» sauvegardé[125000000/125000000]

Citer

Le peering sera remis en place une fois Bouygues Telecom présent directement sur le LyonIX.

N'hésitez pas à mailer peering@kwaoo.net pour ce genre de choses.

vivien · « **Réponse #4 le:** 28 juillet 2012 à 12:00:05 »

C'est pour cette raison que K-Net ne peer pas avec OVH sur LyonIX mais préfère récupérer le trafic via IELO ?

Si K-Net arrive a récupéré Bouygues Telecom sur les route serveur, il devrait aussi récupérer OVH !
OVH (AS16276) est bien présent sur les routes serveur de LyonIX => https://noc.rezopole.net/as_list.html

C'est sur que c'est risqué de faire passer la VoIP sur un lien saturé...

Pour faire un test de débit avec OVh voici les fichiers a utiliser :
IPv4 : wget -O /dev/null http://ipv4.proof.ovh.net/files/1000Mo.dat
IPv6 : wget -O /dev/null http://ipv6.proof.ovh.net/files/1000Mo.dat

Pourtant sur la wethermap du LyonIX, le lien vers Paris est loin d'être saturé...

arnaud · « **Réponse #5 le:** 28 juillet 2012 à 15:29:21 »

Citation de: vivien le 28 juillet 2012 à 12:00:05

C'est pour cette raison que K-Net ne peer pas avec OVH sur LyonIX mais préfère récupérer le trafic via IELO ?

Assez précisèment.

Citer

C'est sur que c'est risqué de faire passer la VoIP sur un lien saturé...

C'est surtout un problème de jitter qui nous à poussé à faire ca.

vivien · « **Réponse #6 le:** 28 juillet 2012 à 17:27:51 »

Je pense que la piste de la saturation du lien Paris <=> Lyon de LyonIX est une mauvaise piste.

J'ai fait quelques tests depuis LaFibre.info, hébergé au Maxnod et qui utilise le peering avec Bouygues Telecom via les routes serveur.
Il semblerait que la dégradation soit lié a un équipement sur le chemin qui triture les paquets.
Bref, je me dit qu'il est peux être possible de résoudre le problème et j'aurais besoin d'un test que je ne peux pas réaliser pour confirmer mon diagnostique.

Cela se met plus en évidence avec un ping important.
J'utilise pour ce faire le serveur 90ms.testdebit.info, serveur plus en ligne aujourd'hui avec un ping supplèmentaire de 90ms (latence générée artificiellement avec NetEm)

Depuis LaFibre.info sur Maxnod :
$ wget -O /dev/null http://90ms.testdebit.info/fichiers/1000Mo.dat 100%[=========================================================================================================>] 125 000 000 247K/s ds 7m 5s 2012-07-28 17:15:06 (287 KB/s) - «/dev/null» sauvegardé [125000000/125000000] $ ping 90ms.testdebit.info PING 90ms.testdebit.info (89.82.180.22) 56(84) bytes of data. 64 bytes from 89.82.180.22: icmp_req=1 ttl=56 time=99.0 ms 64 bytes from 89.82.180.22: icmp_req=2 ttl=56 time=99.0 ms

Depuis un serveur OVH :
$ wget -O /dev/null http://90ms.testdebit.info/fichiers/1000Mo.dat--2012-07-28 17:09:13-- http://90ms.testdebit.info/fichiers/1000Mo.dat
100%[======================================>] 125 000 000 4,59M/s ds 27s
2012-07-28 17:09:40 (4,47 MB/s) - «/dev/null» sauvegardé [125000000/125000000]
$ ping 90ms.testdebit.info
PING 90ms.testdebit.info (89.82.180.22) 56(84) bytes of data.
64 bytes from 89.82.180.22: icmp_req=1 ttl=56 time=94.4 ms
64 bytes from 89.82.180.22: icmp_req=2 ttl=56 time=94.5 ms

Même système d’exploitation sur laFibre.info et OVH, seul la configuration matérielle change (petit serveur OVH avec 1go de ram)
Le ping est presque le même (à 4% prés).

Pourtant on a 4,59 Mo/s a la fin du téléchargement sur OVH et 247 Ko/s à la fin du téléchargement sur LaFibre.info (fichier téléchargé en 27 secondes sur OVH et 7minutes 5 sec sur LAFibre.info)
La différence est incroyable et ce n'est pas une saturation qui explique un si petit débit sur lafibre.info car sans les +90ms, on est à un débit de 2 Mo/s.

vivien · « **Réponse #7 le:** 30 juillet 2012 à 08:17:44 »

Ce n'est pas une saturation, mais des micro-coupures sur le lien qui dégradent fortement le débit (et la VoIP).

J'ai réalisé un téléchargement avec une capture coté client (LaFibre.info sur le Maxnod) et coté serveur (testdebit.info chez Bouygues Telecom) afin de comprendre pourquoi le débit est autant dégradé via le lien qui relie LyonIX aux GiX parisiens => J'observe de nombreuses micro-coupures du lien.

Ce ne sont pas des pertes de petites pertes de paquets, mais des coupure dans le sens Paris -> Lyon ou Lyon -> Paris.

Exemple n°1 : dés le début du téléchargement la connexion va être coupé dans le sens Lyon-> Paris pendant plusieurs dizaines de ms.

L'ensemble des acquittements sont perdus. Le client a envoyé ses acquittements et attend tranquillement le paquet suivant. Le serveur lui aussi a envoyé 32 Ko de données et donc attend un acquittement du client pour continuer. Cet acquittement ne venant pas, il va attendre 206ms avant de renvoyer le dernier paquet non acquitté. Ce paquet a déjà été reçu par le client mais cela va permettre la reprisse de la connexion, le client envoyant un acquittement qui correspond a tous les acquittements non reçus par le serveur.

La connexion repart prudemment. Cela signifie que le serveur ne va pas remplir complètement la fenêtre de réception. Il va attendre régulièrement des acquittements.

Exemple n°2 : Peu de temps après la connexion coupe dans le sens Paris -> Lyon. Là aussi ce n'est pas un paquet de donné mais 12 Ko qui sont perdus. Le serveur stop l'envoi de données n'ayant reçu aucune demande de retransmission du client car l'intégralité des paquets ont été perdus. Après 216ms de pause le serveur va renvoyer le dernier paquet non acquitté. Le client envoi l’accusé de réception. Le serveur va continuer avec le paquet suivant et attend l’acquittement. En effet après ces phénomènes anormaux, le serveur va attendre un acquittement avant d'envoyer le paquet suivant. Là le client va s'apercevoir qu'il lui manque 11 Ko de données. Le client va donc demander une retransmission de tous ces paquets. A la réception de cette demande, le serveur renvoi le reste des paquets perdus.

Suite à ces incidents, La connexion repart prudemment : non seulement le serveur ne va pas remplir complètement la fenêtre de réception et le client ne va pas faire augmenter sa fenêtre de réception qui est adaptative.
=> Les débits entre les coupures de connexions ne seront pas bon.

Cela explique les problèmes de faible débit sur ce lien et les problèmes de mauvaise qualité de la voix sur IP.

J'ai mis à disposition les capture Wireshark dans les des deux sens ici

Weathermap LyonIX au moment de la capture

Voici le wget sur lequel porte la capture :
$ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat --2012-07-28 21:11:28-- http://1.testdebit.info/fichiers/1000Mo.dat Résolution de testdebit.info (testdebit.info)... 89.84.127.55 Connexion vers testdebit.info (testdebit.info)|89.84.127.55|:80... connecté. requête HTTP transmise, en attente de la réponse... 200 OK Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig] Sauvegarde en : «/dev/null» 100%[=============================================>] 125 000 000 2,78M/s ds 54s 2012-07-28 21:12:22 (2,20 MB/s) - «/dev/null» sauvegardé [125000000/125000000]

vivien · « **Réponse #8 le:** 30 juillet 2012 à 10:11:05 »

J'ai mis en place un script pour télécharger un fichier de 30Mo chaque heure depuis LaFibre.info vers deux serveurs Speedtest : Bouygues Telecom et OVH.

Code: [Sélectionner]

#!/bin/dash
wget -O /dev/null http://89.84.127.55/speedtest/random4000x4000.jpg -o /tmp/test_debit_wget.tmp
cat /tmp/test_debit_wget.tmp | grep "31625365/31625365" >> /home/scripts/speedtest_bouygues.txt

wget -O /dev/null http://speedtest1.proof.ovh.net/speedtest/random4000x4000.jpg -o /tmp/test_debit_wget.tmp
cat /tmp/test_debit_wget.tmp | grep "31625365/31625365" >> /home/scripts/speedtest_ovh.txt

On voit bien que ce n'est pas une saturation, le débit étant le même quel que soit l'heure.

Voici les résultats pour OVH : (OVH est récupéré via le SFINX sur Paris suivit du lien Paris => LyonIX)
2012-07-28 21:05:32 (1,67 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 22:05:36 (1,50 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 23:05:32 (1,60 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 00:05:34 (1,49 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 01:05:30 (1,73 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 02:05:30 (1,71 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 03:05:38 (1,31 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 04:05:26 (2,04 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 05:05:27 (1,86 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 06:05:27 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 07:05:27 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 08:05:25 (2,17 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 09:05:31 (1,66 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 10:05:34 (1,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 11:05:32 (1,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 12:05:44 (1,15 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 13:05:33 (1,45 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 14:05:31 (1,67 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 15:05:35 (1,58 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 16:05:37 (1,33 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 17:05:37 (1,37 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 18:05:38 (1,32 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 19:05:30 (1,71 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 20:05:36 (1,42 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 21:05:34 (1,56 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 22:05:34 (1,61 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 23:05:38 (1,38 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 00:05:34 (1,49 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 01:05:33 (1,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 02:05:32 (1,69 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 03:05:39 (1,25 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 04:05:29 (1,88 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 05:05:30 (1,65 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 06:05:36 (1,28 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 07:05:27 (1,88 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 08:05:29 (1,80 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 09:05:39 (1,30 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 10:05:38 (1,30 MB/s) - «/dev/null» sauvegardé [31625365/31625365]

Voici les résultats pour Bouygues Telecom : (Bouygues Teleocm est récupéré via le FranceIX sur Paris suivit du lien Paris => LyonIX)
2012-07-28 00:05:18 (1,70 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 01:05:12 (2,65 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 02:05:11 (2,93 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 03:05:12 (2,56 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 04:05:12 (2,79 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 05:05:12 (2,87 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 06:05:11 (2,92 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 07:05:11 (2,97 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 08:05:11 (3,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 09:05:13 (2,64 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 10:05:14 (2,36 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 11:05:14 (2,33 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 12:05:18 (1,72 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 13:05:19 (1,72 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 14:05:17 (1,92 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 15:05:17 (1,90 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 16:05:15 (2,16 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 17:05:15 (2,21 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 18:05:14 (2,36 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 19:05:14 (2,32 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 20:05:14 (2,35 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 21:05:14 (2,26 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 22:05:16 (2,10 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-28 23:05:13 (2,48 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 00:05:14 (2,45 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 01:05:12 (2,77 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 02:05:13 (2,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 03:05:15 (2,16 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 04:05:11 (2,89 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 05:05:11 (3,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 06:05:11 (2,95 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 07:05:12 (2,76 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 08:05:11 (3,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 09:05:12 (2,59 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 10:05:14 (2,28 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 11:05:13 (2,40 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 12:05:18 (1,81 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 13:05:13 (2,60 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 14:05:13 (2,68 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 15:05:16 (1,99 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 16:05:15 (2,23 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 17:05:15 (2,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 18:05:15 (2,12 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 19:05:12 (2,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 20:05:15 (2,23 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 21:05:14 (2,29 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 22:05:15 (2,14 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-29 23:05:16 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 00:05:14 (2,39 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 01:05:13 (2,55 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 02:05:15 (2,18 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 03:05:15 (2,18 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 04:05:13 (2,61 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 05:05:12 (2,68 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 06:05:13 (2,44 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 07:05:11 (3,06 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 08:05:12 (2,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 09:05:15 (2,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365] 2012-07-30 10:05:15 (2,07 MB/s) - «/dev/null» sauvegardé [31625365/31625365]

vivien · « **Réponse #9 le:** 30 juillet 2012 à 13:25:18 »

Serveur SpeedTest Bouygues Telecom depuis LaFibre.info (Maxnod) après avoir coupé le peering :

2012-07-30 09:05:15 (2,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:05:15 (2,07 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:57:38 (56,1 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 11:05:02 (48,8 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 12:05:01 (51,6 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 13:05:01 (49,3 MB/s) - «/dev/null» sauvegardé [31625365/31625365]

On dépasse 70 Mo/s avec des fichiers un peu plus gros (là c'est un fichier de 30 Mo qui est téléchargé)

vivien · « **Réponse #10 le:** 26 octobre 2012 à 11:11:28 »

Citation de: arnaud le 27 juillet 2012 à 23:12:40

En attendant, j'ai exclu nos annonces vers l'AS 5410 au travers du Route Server du Lyonix et baissé la préférence en sortie (lyonix) de façon à repasser le trafic par nos transits.
Cela semble être effectivement tout de suite mieux :

Code: [Sélectionner]
wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat --2012-07-27 22:48:01-- http://1.testdebit.info/fichiers/1000Mo.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: 125000000 (119M) [application/x-ns-proxy-autoconfig] Sauvegarde en : «/dev/null» 100%[===============================================>] 125 000 000 29,2M/s ds 4,2s 2012-07-27 22:48:05 (28,4 MB/s) - «/dev/null» sauvegardé[125000000/125000000]

Il est possible de remonter le peering avec OVH, Bouygues Telecom et les autres qui avait été coupé, Rezopole / LyonIX a basculé la liaison Lyon <=> Paris sur un nouveau lien 1Gb/s, hier à 15h00.
Le nouveau lien permet de gagner 1ms vers Paris et il n'y a plus de pertes de paquets.
Concrètement le débit de téléchargement moyen d'un petit fichier sur un serveur OVH passe de 800 Kb/s à 42 Mb/s (C'est un débit moyen sur un petit fichier, le débit en fin de téléchargement est bien plus important que ce débit moyen)

butler_fr · « **Réponse #11 le:** 26 octobre 2012 à 14:30:58 »

du coup le ping entre les abonnées bouygues et ceux qui sont chez un autre fai sur lyon devrait être amélioré?
(je n'est pas vus de changement sur mon graph smokeping)