La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: vivien le 28 février 2015 à 17:17:24
-
OVH promet un "Internet neutre et sans bridage" nous allons voir que ce n'est pas le cas systématiquement, mais surtout que les clients ne sont pas prévenus.
Une des sociétés victimes de ce bridage est 4Gmark, vous savez le test de débit proche d'un usage client (et donc sur une seule connexion TCP).
La cause du bridage réalisé par OVH, est probablement une trop grosse consommation de data.
Une hypothèse est aussi que 4Gmark n'a pas pris les options nécessaires vu sa consommation.
Édit : On sait depuis que 4Gmark a pris un serveur à 122€/mois, qui dispose d'une bande passante de type "Garantie" de 500 Mb/s vers Internet (OVH vers Internet). Le trafic cumulé, consommé sur le mois de février, est de seulement 1 To, ce qui est très faible (on dépasse rarement les 10 Mb/s de débit moyen sur 5 minutes) :
(https://lafibre.info/images/ovh/201502_ovh_4gmark_volume_serveur_gravelines.jpg)
4G mark, qui avait deux serveurs chez OVH, a supprimé le serveur bridé et ses mesures.
4Gmark est maintenant présent sur le cloud de Mediactive network.
L’application 4Gmark :
(https://lafibre.info/images/bbox_debit/201312_bbox_fibre__fttla100_samsung_galaxy_s4_22.png)
A l'origine de mes recherches, de tests excessivement mauvais, qui ont d'ailleurs été remontés sur twitter :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_twitter_free_1.png)
(https://lafibre.info/images/ovh/201502_ovh-4gmark_twitter_free_2.png)
L’application 4Gmark utilise deux serveurs qui sont tous les deux chez OVH (le premier sur le datacenter de Roubaix et le second sur le datacenter de Gravelines)
J'ai repéré des phénomènes étranges sur le serveur de Roubaix (très forte gigue qui fait que les paquets arrivent dans le désordre à très haut débit) mais il est difficile d'en savoir plus sur l'origine, sans trace coté serveur. De plus la gigue n’empêche pas d'avoir des débits corrects - en tout cas à des années lumières du serveur de 4Gmark de Gravelines.
Je concentre donc mon investigation sur le serveur 4Gmark de Gravelines.
-
Débit en téléchargeant un fichier de 125 Mo sur le serveur 4Gmark de Gravelines depuis LaFibre.info (Adeli) : on est à 12,5 Mb/s alors qu'on devrait aller à plus de 700 Mb/s.
(https://lafibre.info/images/ovh/201502_ovh-4gmark_adeli_debit.png)
1306 paquets perdus, dés le début du téléchargement :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_adeli_perdu.png)
Le début du téléchargement (il dure 79,7 secondes) en graphe TCP trace qui permet de voir les retransmissions de paquets :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_adeli_tcptrace.png)
Le traceroute vers le serveur ne relève rien de particulier : le ping est bon (LaFibre.info est dans l'Ain) et il n'y a pas de saturation qui sont visibles par des pertes de paquets ou une augmentation de la latence :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_adeli_traceroute.png)
1ère Hypothèse : Saturation sur le peering entre OVH et Adeli (qui se fait sur Equinix Internet Exchange Paris)
-
Débit en téléchargeant un fichier de 125 Mo sur le serveur 4Gmark de Gravelines depuis Bouygues Telecom : on est à 23,8 Mb/s alors qu'on devrait aller à plus de 800 Mb/s.
(https://lafibre.info/images/ovh/201502_ovh-4gmark_bouygues_debit.png)
2222 paquets perdus, dés le début du téléchargement :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_bouygues_perdu.png)
Le début du téléchargement (il dure 42 secondes) en graphe TCP trace qui permet de voir les retransmissions de paquets :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_bouygues_tcptrace.png)
Le traceroute vers le serveur ne relève rien de particulier : le ping est bon et il n'y a pas de saturation qui sont visibles par des pertes de paquets ou une augmentation de la latence :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_bouygues_traceroute.png)
Des débits catastrophiques sont également observés avec les autres FAI.
2ème Hypothèse : Peu de chance que tous les opérateurs sature leur peering avec OVH, donc le problème est probablement chez OVH, par exemple le lien entre PAris et le datacenter OVH dEgravelines.
-
Je me fait donc prêter un serveur OVH qui est à Gravelines, connecté sur le même routeur que celui de 4Gmark.
Le traceroute est strictement identique au serveur 4Gmark et le ping est identique :
(https://lafibre.info/images/ovh/201502_ovh-gra_adeli_traceroute.png)
Débit en téléchargeant un fichier de 100 Mo sur le serveur OVH de Gravelines depuis LaFibre.info (Adeli) : on est à 690 Mb/s de débit moyen sur ce petit fichier. On sature bien le 1 Gb/s, c'est le temps de la montée en débit à cause du ping qui fait que le débit moyen est < 900 Mb/s.
(https://lafibre.info/images/ovh/201502_ovh-gra_adeli_debit.png)
Un seul paquet perdu, en fin de téléchargement :
(https://lafibre.info/images/ovh/201502_ovh-gra_adeli_perdu.png)
Le graphe TCPtrace est parfait sauf à la fin (en haut à droite) :
(https://lafibre.info/images/ovh/201502_ovh-gra_adeli_tcptrace.png)
-
Test depuis Bouygues Telecom sur le serveur de test qui est à coté de celui de 4Gmark
Là aussi, le traceroute est strictement identique au serveur 4Gmark et le ping est identique :
(https://lafibre.info/images/ovh/201502_ovh-gra_bouygues_traceroute.png)
(https://lafibre.info/images/ovh/201502_ovh-gra_bouygues_debit.png)
Strictement aucune perte de paquet !
(https://lafibre.info/images/ovh/201502_ovh-gra_bouygues_perdu.png)
Un graphe TCPtrace parfait :
(https://lafibre.info/images/ovh/201502_ovh-gra_bouygues_tcptrace.png)
Le weathermap d'OVH confirme que aucun lien n'est saturé sur le chemin emprunté :
(https://lafibre.info/images/ovh/201502_ovh-gravelines_weathermap.png)
3ème Hypothèse : Vu que ni le réseau OVH, ni les peering ne saturent, c'est le serveur de 4G mark qui est sur-chargé et qui répond donc avec un faible débit.
-
Pour vérifier si c'est le serveur 4Gmark qui sature, j'utilise le serveur OVH qui est situé à coté pour tester le débit sur 4Gmark.
Le traceroute, bien évidement réduit à sa plus simple expression :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_ovh-gra_traceroute.png)
Le débit est excellent, avec le ping qui est quasi nul, le débit monte immédiatement à 1 Gb/s :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_ovh-gra_debit.png)
Pas de paquet perdu :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_ovh-gra_perdu.png)
Graphe TCPtrace parfait :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_ovh-gra_tcptrace.png)
Conclusion : La conclusion s'impose : OVH a bridé le débit du serveur 4Gmark, probablement car il consomme trop d'internet. Est-ce légal vis à vis des CGV ? Il faudrait savoir quelle offre à souscrit 4Gmark. Ce qui est grave, c'est que 4Gmark n'a pas été averti et que cela décrédibilise leur test de débit.
-
Fonctionnement du bridage pour les serveurs OVH qui consomment beaucoup d'Internet : Il n'est pas actif la nuit
Une certitude : cela ne concerne que le trafic à destination d'Internet. Le trafic dans le réseau OVH n'est pas impacté.
2 hypothèses pour expliquer que le débit revienne à la normale la nuit :
- Soit le bridage n'est effectué que quand le trafic est important sur le réseau OVH (c'est là qu'il coûte de l'argent à OVH)
- Soit le bridage n'est pas activé la nuit car le trafic sur le serveur 4Gmark est plus faible (moins de test la nuit, c'est logique)
Je ne sais pas qu'elle est la bonne hypothèse, mais voici le graphe du débit en fonction de l'heure :
(https://lafibre.info/images/ovh/201502_ovh-4gmark_debit.png)
Un point représente un test (un téléchargement d'un fichier de 125 Mo sur le serveur 4Gmark ou 100 Mo sur le serveur alternatif de test)
-
Outch ! #popcorn
-
est-ce que par hasard tu sais quel type de serveur a 4G mark ? et quel type de bande passante ??
https://www.ovh.com/fr/serveurs_dedies/upgrade-bande-passante.xml
Après c'est pas nouveau chez OVH, c'est de la BP garantie si tu ne l'utilises pas trop. (c'est en 2013 je crois que çà a été annoncé quand çà "saturait" trop ...
OVH vous garantit des niveaux de bande passante interne, entrante et sortante différentes en fonction du modèle de serveur dédié. Cette bande passante est garantie dans le cadre d’un usage normal (upgrade et usage spécifique en option) et profite de l’ensemble de l’infrastructure réseau OVH (interconnexions Ultimate).
-
est-ce que par hasard tu sais quel type de serveur a 4G mark ? et quel type de bande passante ??
Question assez intéressante, si c'est du best-effort avec une garantie bien en deçà des besoins, je n'irai pas forcement jeter la pierre à OVH.
-
4Gmark m'apporte des précisions : 4Gmark a une offre OVH avec un débit garanti de 500 Mb/s sur ce serveur.
Le trafic réel est très faible :
(https://lafibre.info/images/ovh/201502_ovh_4gmark_debit_serveur_gravelines.jpg)
Le volume utilisé sur le mois de février cumulé est très faible : moins de 1 To
(https://lafibre.info/images/ovh/201502_ovh_4gmark_volume_serveur_gravelines.jpg)
Le serveur de 4G mark sur Gravelines :
Serveur Enterprise SP-64 - 64G
Connexion réseau : 1 Gbps
BP OVH/OVH : 1 Gbps
BP OVH/Internet : 500 Mbps
BP Internet/OVH : 1 Gbps
-
Seule hypothèse du bridage : la configuration réseau d'OVH.
OVH utilise du Cisco, notamment la gamme Nexus pour les connexions serveurs. Cette gamme a une particularité, les modèles série 2000 sont des extensions (Fabric EXtender = FEX) du ou des switches parents. Ces modèles s'installent dans les racks serveurs (configuration dite Top-Of-Rack) et sont reliés en fibre optique avec leurs parents et ne possèdent aucune intelligence, strictement aucune. L'intéret ? En gros, c'est du jetable (malgré le tarif...) s'il tombe en panne, il suffit de le remplacer, la configuration sera rechargée sans intervention humaine.
Ces modules FEX n'ayant aucune intelligence, ils ne sont meme pas capable de commuter le trafic -> tout le trafic interne à un module FEX remonte à son (ou ses) switch(es) parent(s). Au maximum, il y a 4 liens montants 10Gb pour les versions 1Gb ou 8 liens montants 10Gb pour les versions à 10Gb. Ces liens sont donc utilisés que le trafic sorte du switch ou soit destiné à une autre machine du meme switch.
Toutes ces connexions sont ramenés à deux switches Cisco Nexus série 5500 : elles sont toutes actives, c'est une configuration dite "dual-homed" où les modules FEX sont gérés par deux parents. Si on perd un parent (donc un Nexus 5500), il n'y a pas d'impact sur les modules FEX, excepté une réduction de bande passante en sortie vue la perte de la moitié des liens montants.
Les Cisco Nexus série 5500 sont en 10Gb uniquement, seule la série 5600 récemment sortie dispose de ports 40Gb. Afin d'avoir un maximum de bande passante, on peut agréger des interfaces depuis chaque Nexus 5500 vers le backbone -> c'est la configuration choisie par OVH.
Possibilité : si OVH a des Cisco 5548 : 32x 10Gb répartis en 20x connexions vers les FEX (modèles 1Gb), 2x vers l'autre Nexus 5500, reste 10x connexions mais d'après Weathermap, une seule serait utilisée (ratio x2 en %)
Quand le serveur 4G mark monte à 1Gb, cela représente 10% de bande passante sur un uplink de FEX et 10% aussi sur l'uplink des N5k (meme avec 2 liens, Cisco fait de l'équilibrage par session).
Si le serveur 4Gmark atteint trop souvent 1Gb, le risque de saturation augmente d'autant.
Les Nexus 5500 n'ont pas de capacité de bridage donc celui-ci est effectué sur les routeurs OVH, probablement au plus proche: gra-3a-a9 (a9 = ASR9k ?).
-
4Gmark va chercher la date de début de bridage OVH, pour déscoper les mesures des résultats de février.
En attendant, il ont basculé très rapidement chez Mediactive Network, un hébergeur qui offre une grande qualité vers tous les opérateurs (j'ai déjà réalisé des tests)
(https://lafibre.info/images/ovh/201502_ovh_4gmark_bascule_chez_mediactive.png)
Le bridage du serveur par OVH me semble encore plus incompréhensible :ce n'est pas un serveur à 30€/mois, mais à 122€/mois.
Le serveur de 4Gmark (source Archive.org (http://www.archive-com.com/page/2927576/2013-09-26/https://www.ovh.com/fr/serveurs_dedies/eg_64g.xml) le 26 septembre 2013, car OVH a fait évoluer ses offres depuis) :
Il est bien mentionné une bande passante de type "Garantie" de 500 Mb/s vers Internet (OVH vers Internet).
(https://lafibre.info/images/ovh/201502_ovh_4gmark_spec_serveur_gravelines.png)
-
Et on sait ce qu'a répondu le support d'OVH par rapport à ce constat de bridage?
Leon.
-
@vivien : Garantie c'est OVH c'est comme je l'ai dit plus haut (https://lafibre.info/ovh-datacenter/bridage-ovh/msg205942/#msg205942) sous condition de ne pas trop utiliser.
-
Autre question, ça ne pourrait pas être un bug vicelard?
On part du principe que c'est une action volontaire là, mais n'y aurait il pas de la place pour une petite part de doute?
-
Bug ou typologie de trafic qui ne plaît pas au serveur qui analyse si il y a usage abusif.
Dans les deux cas c'est grave, aggravé par la non information du client.
Pour le terme bande passante de type "Garantie" de 500 Mb/s, je n'ai fait que reprendre la formulation OVH, cf copie d'écran.
-
Il y a débit garanti et abus.
1G garanti c'est différent d'un port 1G sur un point d'échange. Pourtant c'était ce à quoi ressemblait le serveur 4G mark ?
Pour moi les serveurs de speedtest sont des cas spéciaux, comme peuvent l'être les relais P2P, les nœuds Tor ou les serveurs de streaming (de mémoire utilisation interdite dans les CGV, il faudrait que je les relise). Ce qui est "grave" c'est surtout le manque d'information et la non alerte du client. J'espère donc que c'est un bug plutôt qu'une action automatique qui fait ça dans son coin sans prévenir personne
-
Encore une fois, est-ce qu'on sait si le support d'OVH a été contacté, et est-ce qu'on sait ce qu'ils ont répondu?
Leon.
-
Y'a pas une application sur le serveur qui indique des stats ? y'a combien de tests 4GMark par jour en moyenne ?
Vu comme ca on dirait juste un probleme de saturation du serveur, peut-être trop de clients 4GMark simultanés en moyenne par rapport a la connectivité du serveur ?
-
Voici les statistiques :
Le trafic réel est très faible :
(https://lafibre.info/images/ovh/201502_ovh_4gmark_debit_serveur_gravelines.jpg)
Le volume utilisé sur le mois de février cumulé est très faible : moins de 1 To
(https://lafibre.info/images/ovh/201502_ovh_4gmark_volume_serveur_gravelines.jpg)
-
Oui j'avais vu ce graphe mais ca ne donne pas d'info sur le nombre moyen de clients simultanés.
C'est juste un serveur web et ftp alors ? il n'y a pas d'application spécifique 4GMark dessus ?
-
Pour moi, il ne devrait y avoir aucune notion d'abus ou non de la bande passante. Quand on paye pour une bande passante garantie, on doit pouvoir l'utiliser.
La condition d'utilisation "en bon père de famille" pour les forfaits mobiles je veux bien comprendre, mais pour un serveur à débit garanti moins.
-
Ce sont des fichiers sur un serveur apache téléchargé par l’application Adroid / iPhone
Par exemple le fichier de 125 Mo (soit 1Gb) : http://ns425929.ip-37-187-148.eu/4Gmark/dl/125000000.file
Pour comparer le débit, de mon coté je n'ai pas 125 Mo, mais 100 Mo ou 200 Mo : http://1-ipvbouygues.testdebit.info/fichiers/100Mo.dat ou http://1-ipvbouygues.testdebit.info/fichiers/200Mo.dat (j'ai précisé IPv4 car si le test est fait avec http://1.testdebit.info/fichiers/100Mo.dat si IPv6 est dispo, le transfert se fait en IPv6. Or le nom de domaine du serveur 4Gmark est en IPv4 uniquement).
-
Y'a pas une application sur le serveur qui indique des stats ? y'a combien de tests 4GMark par jour en moyenne ?
Vu comme ca on dirait juste un probleme de saturation du serveur, peut-être trop de clients 4GMark simultanés en moyenne par rapport a la connectivité du serveur ?
Vivien a démontré:
- qu'on emplafonnait le Gb de serveur à serveur en interne OVH donc ça ne vient pas du serveur
- que le débit vers un serveur voisin ne souffrait pas de ce phénomène
- que le débit vers le serveur 4Gmark est fonction de l'heure de la journée avec de grosses variations
OK, on peut continuer de tout vérifier mais ça me semble quand meme indiquer un bridage.
-
Vivien a démontré:
- qu'on emplafonnait le Gb de serveur à serveur en interne OVH donc ça ne vient pas du serveur
- que le débit vers un serveur voisin ne souffrait pas de ce phénomène
- que le débit vers le serveur 4Gmark est fonction de l'heure de la journée avec de grosses variations
OK, on peut continuer de tout vérifier mais ça me semble quand meme indiquer un bridage.
J'avais tout lu avant mon 1er post et pris ces points en considération également mais:
- le débit interne OVH - interne OVH est une autre classe de service limitée a 1Gbps et pas 500Mbs donc n'est pas représentatif du meme 'chemin' ou du même traitement (range ip par exemple sur le serveur voir de la meme interface (s'il en a plusieurs). Ca ne prouve rien pour moi.
- Le serveur de prêt peut sortir vers internet a 1Gbps d'apres les tests et ne plafonne pas a 500Mbps donc ca n'est pas la meme offre OVH. Aussi ce serveur de test n'est pas chargé et sollicité par plein de clients 4GMark comme le serveur qui a un souci.
- La variation de débit jour/nuit peut être liée a moins de clients simultanés la nuit si c'est un probleme de charge.
En faisant des tests en multi-connexions au lieu d'une seul connexion TCP on arrive a bon débit (j'ai un pic a 450Mbps avec 20 connexions en parallèle sur le fichier en question).
A mon avis il y a une limitation par connexion TCP qui semble variée la nuit donc fonction du nombre de totales de connexions actives ou quelque chose , peut-etre du a OVH, qui limite la rwin par connexion et pas de facon global (le serveur peut cracher 500Mbps vers Internet). Reste a voir si cette limitation par connexion est du au serveur lui-même (config, paramétrage) ou a OVH.
-
- le débit interne OVH - interne OVH est une autre classe de service limitée a 1Gbps et pas 500Mbs donc n'est pas représentatif du meme 'chemin' ou du même traitement (range ip par exemple sur le serveur voir de la meme interface (s'il en a plusieurs). Ca ne prouve rien pour moi.
1Gb c'est le débit de la connexion du serveur, c'est pas une classe de service : ça n'existe pas sur Nexus.
- La variation de débit jour/nuit peut être liée a moins de clients simultanés la nuit si c'est un probleme de charge.
Et dégringoler à quelques dizaines de Mb/s alors que la charge globale du serveur n'est guère supérieure ?
-
Classe de service était a prendre au sens offre/contrat pas forcement mise en oeuvre par une classe de service au sens technique.
J'ai vraiment plus l'impression d'un probleme de limitation de débit par connexion (pb classique rwin par exemple? ce qui pourrait expliquer que ca speed entre les 2 serveurs vu la très faible latence) et pas un bridage global de son débit.
Enfin je sais pas mais la 1ere chose à faire dans ce genre de cas est quand même de se connecter sur le serveur et regarder en détail sur ce qui s'y passe avant d'aller mettre en cause OVH (qui peut être en faute c'est tout a fait possible) à partir de tests externes. Il y a pas mal de diagnostics locaux et autres tests possibles à faire sur le serveur. Même a distance d'ailleurs, les 2 premiers tests postés ici notamment devraient être refait en multi-connexions (avec axel par exemple ou en lançant plusieurs wget en meme temps).
-
Sujet intéressant s'il en est.
-
Ça fait plus d'un an qu'on dit qu'un test de débit ne peut se reposer que sur un seul hébergeur ...
CQFD.
On a désormais plus de 80 serveurs sur http://app.nperf.com ;)
-
La condition d'utilisation "en bon père de famille" pour les forfaits mobiles je veux bien comprendre, mais pour un serveur à débit garanti moins.
L’expression juridique « en bon père de famille » disparaît du droit en vigueur
La loi pour l’égalité réelle entre les femmes et les hommes, publiée le 4 août 2014, remplace l’expression juridique « en bon père de famille ».
Cette expression renvoyait à l’idée du comportement normal d’une personne titulaire d’un droit, spécialement d’un droit d’usage sur le bien d’autrui, obligée d’être normalement prudente, diligente et soigneuse. L’obligation s’appliquait évidemment, en droit, à l’homme comme à la femme, parent d’enfant comme sans enfant. Le Code civil employait l’expression dans plusieurs articles. Elle se trouvait encore dans d’autres codes.
En 1982, la loi sur les droits et les devoirs des bailleurs et locataires avait déjà substitué à l’obligation « de jouir des locaux en bon père de famille » celle d’en jouir « paisiblement ». Le locataire était ainsi tenu « d’user paisiblement de la chose louée » suivant la destination donnée par le contrat de location.
Le 21 janvier 2014, l’Assemblée nationale avait adopté un amendement supprimant cette expression du droit français et la remplaçant par le terme « raisonnable » ou « raisonnablement ». La loi pour l’égalité réelle entre les femmes et les hommes confirme cette suppression.
Pour en savoir plus
LOI n°~2014-873 du 4~août~2014 pour l'égalité réelle entre les femmes et les hommes
Légifrance, le service public de la diffusion du droit
Source : http://www.service-public.fr/actualites/003245.html
REMARQUE
Cette notion juridique n'a rien à voir avec la notion d'usage "raisonnable" d'un service de télécommunication!
L'utilisation de cette terminologie pour un consommateur n'a rigoureusement aucun sens.
-
REMARQUE
Cette notion juridique n'a rien à voir avec la notion d'usage "raisonnable" d'un service de télécommunication!
L'utilisation de cette terminologie pour un consommateur n'a rigoureusement aucun sens.
C'était pourtant dans les conditions des forfaits mobile de Free, en regard de l'usage d'internet "illimité".
-
Et on sait que les contrats Free sont bétons...
trololol
-
Vivien.... t'es trop fort ;D
-
Bonjour.
Avec ZDnet on apporte notre retour face à ce problème du serveur OVH remonté par Vivien. Notre vision et la gestion de ce pb :
http://www.zdnet.fr/actualites/resultats-fausses-4gmark-s-explique-39815926.htm