La Fibre
Télécom => Réseau => 
Baromètre (Comparatif des FAI) => Discussion démarrée par: vivien le 11 février 2015 à 12:11:23
-
Baromètre M-Lab decembre 2014
- Le test de débit : http://www.measurementlab.net/ (http://www.measurementlab.net/)
- La publication des données (https://www.google.com/publicdata/explore?ds=e9krd11m38onf_&ctype=l&strail=false&bcs=d&nselm=h&met_y=download_throughput&scale_y=lin&ind_y=false&rdim=country&idim=country:40:208:250:276&idim=city:36_nsw_sydney&idim=region:840_ca:840_ny&ifdim=country&hl=en_US&dl=en_US&ind=false&icfg#!ctype=l&strail=false&bcs=d&nselm=h&met_y=download_throughput&scale_y=lin&ind_y=false&rdim=country_isp&idim=country_isp:250_12844:250_12322:250_16028:250_12566:250_21502&ifdim=country_isp:country:250&hl=en_US&dl=en_US&ind=false)
Le débit médian : (haut débit et très haut débit mélangés)
(https://lafibre.info/images/barometre/201412_m-lab_debit_median.png)
-
Le ratio médian de la durée du test passé dans l'état du réseau saturé : (aka congestion-limited)
Free et Orange ont vraiment un réseau régulièrement saturé
(https://lafibre.info/images/barometre/201412_m-lab_ratio_duree_sature_median.png)
-
Le pourcentage de retransmission de paquet : (les paquets peuvent êtres perdus a cause de CRC sur la ligne ADSL, le WiFi ou de saturation sur le réseau)
Free et Orange ont le plus de pertes de paquets (donc de lenteurs)
(https://lafibre.info/images/barometre/201412_m-lab_retransmission_paquet_median.png)
-
Neutralité de l'Internet :
http://netneutralitymap.org qui utilise les données M-Lab
N°1 : OVH => 0% de tests shaped
N°2 : SFR => 3,4% de tests shaped
N°3 : Bouygues Telecom => 4,2% de tests shaped
N°4 : Numericable => 5,9% de tests shaped
N°5 : Orange => 7% de tests shaped
N°6 : Free => 10,9% de tests shaped
(https://lafibre.info/images/barometre/201412_m-lab_neutralite.png)
-
Il va falloir que NC investisse dans ses infrastructures : son réseau HFC semble de plus en plus saturé et en perte de vitesse côté débits (forcèment, avec le nombre de nouveaux clients, surtout ceux de Bouygues plus ceux à venir de SFR, les saturations vont aller en empirant).
Je n'ai malgré tout pas tout compris sur comment étaient réalisés ces tests ? A la SamKnows ou via des tests réguliers sur des serveurs dédiés par des particuliers testeurs ?
-
Les données sont issues des tests réalisés par le grand public sur http://www.measurementlab.net/tools/ndt
C'est comme nPerf, sauf que le test donne plus d'informations détaillées sur la connexion.
-
Merci :)
-
Free n'a toujours pas retrouvé son niveau de Juillet 2013 ?! :-\
Orange pas terrible non plus depuis plusieurs mois
-
Qu'est ce que veut dire cette mesure de congestion ? J'ai du mal à l'interprêter....
An NDT test can be in 3 different states. Each state represents different conditions that limit the data sent by the server to the client.
network-limited, when the network is congested.
The web00 variable web100_log_entry.snap.SndLimTimeCwnd reports the time spent in this state.
receiver-limited, when the receiver (client) limits the data that can be received.
The web00 variable web100_log_entry.snap.SndLimTimeRwin reports the time spent in this state.
server-limited, when the server limits the data that can be sent.
The web00 variable web100_log_entry.snap.SndLimTimeSnd reports the time spent in this state.
This state can happen because
The uplink is congested. Note however that M-Lab servers are specially (over)provisioned to avoid this case.
The server cannot send as much data as the network and the receiver would allow, in specific phases of the tests. This usually happens during slow start, especially with fast networks and high values of initial window.
The server cannot send as much data as the network and the receiver would allow, during the whole test. This can happen for specific TCP configurations (e.g., if GSO is on). However, this kind of configuration is disabled by default on M-Lab servers.
Est-ce nécessairement une mauvaise chose que la mesure soit "network-limited" ? Ca semble en tout cas un état plus sain que "client limited" - ou plus probable que "server limited".
Je viens de faire un test: j'obtiens des informations relativement contradictoires.
NDT test run towards M-Lab server
ndt.iupui.mlab3.par01.measurement-lab.org
RTT between client and M-Lab server
12 ms
DOWNLOAD SPEED
92.4 Mbps
UPLOAD SPEED
5.4 Mbps
Client System Details
OS data:: Linux, Architecture: x86
Flash Info: Version = LNX 16,0,0,257
The slowest link in the end-to-end path is a
45 Mbps T3/DS3 subnet
Information: Other network traffic is congesting the link
This connection is network limited 97.06% of the time
45 Mbps T3/DS3 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.
Web100 reports the Round trip time = 26.74ms
the Packet size = 1448bytes
No packet loss - but packets arrived out-of-order 0.00% of the time
C2S throughput test: Packet queuing detected: 1.82%
S2C throughput test: Packet queuing detected: 1.82%
Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgement:
ON
RFC 896 Nagle Algorithm:
ON
RFC 3168 Explicit Congestion Notification:
OFF
RFC 1323 Time Stamping:
ON
RFC 1323 Window Scaling:
ON; Scaling Factors - Server=7, Client=7
The theoretical network limit is 413.15 Mbps
The NDT server has a 388.66 KByte buffer which limits the throughput to 227.12 Mbps
Your PC/Workstation has a 1538.50 KByte buffer which limits the throughput to 449.51 Mbps
The network based flow control limits the throughput to 112.79 Mbps
Client Data reports link is T3;
Client Acks report link is Ethernet
Server Data reports link is OC-48
Server Acks report link is OC-48
La vitesse de téléchargement semble indiquer de bon résultats, malgré une "congestion" affichée à 97.1%...
Un subnet DS3 est signalé à 45 mbps, mais ça ne semble pas trop affecter la mesure.
-
Le test NDT devrait mieux expliquer chaque ligne.
Un des concepteur devrait faire un article pour tout expliquer.
Autre chose : l'hébergement du serveur compte pour beaucoup, il devraient mieux détailler la connectivité du serveur de test.
Les pré-requis pour héberger NDT sont également très importantes : 3 serveurs avec des spécifications très précises, un switch qui doit être d'un modèle précis et dédié aux tests, ect...
Cela serait bien de baisser le ticket d'entrée pour multiplier les serveurs...
-
Cela serait bien de baisser le ticket d'entrée pour multiplier les serveurs...
J'en connais un qui aimerait bien héberger un de leur serveurs ;)
-
Je viens de faire un test: j'obtiens des informations relativement contradictoires.La vitesse de téléchargement semble indiquer de bon résultats, malgré une "congestion" affichée à 97.1%...
C'est pas "congestion" mais limité:
This connection is network limited 97.06% of the time
Ca veut simplement dire que c'est le réseau entre ta machine et le serveur qui a limité le débit et pas ta machine ou le serveur.
C'est pas pour autant qu'il est congestionné.
C'est l'un des avantages de NDT par rapport a d'autre speedtest: il détecte s'il y a une limitation coté client ou coté serveur.
Par exemple chez moi, ca donne:
This connection is receiver limited 17.96% of the time
This connection is sender limited 23.38% of the time
This connection is network limited 58.66% of the time
(pour un résultat de 580 Mbps / 80 Mbps)
Donc ma mesure est faussée par une limitation des machines a chaque bout, sans doute une limitation cpu.
Dans ton cas, la mesure n'est pas faussée donc tu as un résultat quasi 100% réseau donc représentatif de ce qui s'est passé sur le réseau et pas aux extrémités.
Le protocole de test (ce qui se passe entre le client et le serveur) est détaillé ici: https://code.google.com/p/ndt/wiki/NDTProtocol (https://code.google.com/p/ndt/wiki/NDTProtocol)
La méthodologie et les explications sur les valeurs affichées sont détaillées ici: https://code.google.com/p/ndt/wiki/NDTTestMethodology (https://code.google.com/p/ndt/wiki/NDTTestMethodology)
On remarquera qu'actuellement le test utilise des 'samples' de 10 secondes seulement ce qui, sur du THD, peut fausser fortement les résultats.
-
Merci pour les explications. Donc si je reprends la page qui indique comment sont tracés les graphes du m-lab (https://code.google.com/p/m-lab/wiki/PDEChartsNDT), c'est bien le temps passé dans l'état "limité par le réseau" qui est représenté dans le deuxième graphique posté par Vivien.
Network-limited ratio and client-limited time ratio
An NDT test can be in 3 different states. Each state represents different conditions that limit the data sent by the server to the client.
network-limited, when the network is congested.
The web00 variable web100_log_entry.snap.SndLimTimeCwnd reports the time spent in this state.
receiver-limited, when the receiver (client) limits the data that can be received.
The web00 variable web100_log_entry.snap.SndLimTimeRwin reports the time spent in this state.
server-limited, when the server limits the data that can be sent.
The web00 variable web100_log_entry.snap.SndLimTimeSnd reports the time spent in this state.
This state can happen because
The uplink is congested. Note however that M-Lab servers are specially (over)provisioned to avoid this case.
The server cannot send as much data as the network and the receiver would allow, in specific phases of the tests. This usually happens during slow start, especially with fast networks and high values of initial window.
The server cannot send as much data as the network and the receiver would allow, during the whole test. This can happen for specific TCP configurations (e.g., if GSO is on). However, this kind of configuration is disabled by default on M-Lab servers.
Du coup, comment interpréter ce graphique, les différences entre FAI, et les évolutions ?
Limitation côté client ?
Les clients de Bouygues Telecom feraient-ils davantage de tests depuis des smartphones qui manquent de ressources ?
Les clients Numéricable auraient-ils massivement changé de clients en un an ?
Limitation côté serveur ?
Mais pourquoi vers un FAI plutôt qu'un autre ?
-
Merci beaucoup pour ces infos tres intéressante, et pour les explications des résultats.
-
Effectivement ce 2eme graphe me met le doute sur la compréhension des datas maintenant :o
Tout seul il n'est pas facile de le comprendre car la donnée est un %age lié a 2 autres valeurs (receiver-limited et server-limited) dont la somme des 3 fait toujours 100% (si j'ai bien compris).
Il faudrait donc aussi le graphe "receiver-limited time" pour voir la répartition des 3 valeurs. (la 3eme se déduisant des 2 autres, idealement un graphe a 3 zones colorées par opérateur serait plus judicieux).
Je vais étudier cela plus en détail.
-
Merci kgersen.
Je suis aussi intéressé, pour savoir si le graphe "Network-limited time ratio" est pertinent ou pas.
J'aimerais savoir aussi si le graphe "Percentage of tests in congestion avoidance" est pertinent (je ne l'ai pas publié)
-
Ce post me sert de bloc-notes, vous pouvez zappé au besoin:)
J'ai fait quelques tests en changeant la négociation ethernet de mon PC.
Quand je le met a 100 Mbps ou 10 Mbps, j'obtient un résultat avec quasi 100% de "receiver-limited time" donc deja le test detecte bien une limitation coté client, pas une limitation cpu mais réseau dans le cas présent (dernier tronçon réseau donc).
Ca voudrait dire que sur des clients Wifi par exemple et des connexions Internet coax (NC, BT) on aurait plus souvent du 'receiver-limited' que du 'network-limited' ce qui correspond bien aux courbes avant fin 2013.
L’interprétation est donc délicate à faire:
Les courbes pour Free/FT(Orange) indique simplement que la plupart de temps le débit est limité par le réseau. ou ? on ne peut savoir, en tout ca cela n'est pas la connectivité du client ou du serveur qui est le maillon lent: globalement les clients de Free et Orange ne sont pas ralenti pas leur equipements (pc ou autre). c'est comme ca qu'il faut comprendre ce graphe.
Pour NC/BT ca serait donc le client qui est en général plus lent que la connexion mais :
Que s'est-il passé à partir de l'automne 2013 pour que NC , BT et SFR commencent a changer progressivement de "receiver-limited" vers "network-limited"
Est-ce lié au déploiement progressif de Windows 8.1 (censé mieux marché en mono-connexion tcp haut débit) ou une montée en débit des connexions Wifi ou un changement de version du test? Une évolution progressive des PC (puissance/connectivité) ? En l'état, on n'a pas assez d'info pour trancher la question.
Ce test n'est pas vraiment connu du grand public francais contrairement a SpeedTest.net par exemple donc on ne sait pas trop qui l'utilise , et si ca correspond au profil moyen des utilisateurs de chaque FAI.
Je ne m'explique pas non les résultat de SFR sauf si les mesures concernent principalement des connexions fibre (probleme de l'audience de ce test). (comment comprendre que les equipements des client sont plus lents que des connexions ADSL sinon? ou alors y'a du mobile dans l'histoire...mystere).
La courbe 'Percentage of tests in congestion avoidance' donne Free/FT a 90% et NC/BT/SFR a 70% et pas de changement pour eux apres l'automne 2013... encore un mystère ?
On reprend donc la compréhension du test depuis la base:
(http://wiki.m-lab.googlecode.com/git/ndt_explanation.png)
Il ne mesure qu'une seul connexion TCP pendant 10s donc ca ne donnera pas forcement le 'max download speed', notamment en THD.
Les infos 'spéciales' sont principalement collecter par le serveur et dans le sens server->client (download), l'upload est la a titre indicatif et pas forcement vraiment pertinent.
Le résultat donne 3 pourcentages répartis entre server, network ou client. A priori server-limited est rare donc on l'exclu. Reste network et client.
Un point important pour certaines courbes, les données sont prises en compte uniquement si "CongSignals > 1" (ligne CongestionSignals dans le détail du test). C'est le cas de la courbe "Download throughput" par exemple mais pas des courbes network-limited et receiver-limited ... donc ca ne porte pas sur les memes données déja...
Un PC en Ethernet a 10Mbps sur ma connexion fibre va avoir CongSignals a 0 donc ne sera pas pris en compte dans la moyenne de "Download throughput" de mon opérateur, ce qui me parait une bonne chose mais ce test sera pris en compte dans les 2 autres graphes...
Ca veut donc dire que tout les tests ou le client est plus lent que la connexion ne sont pas pris dans la moyenne de débit par opérateurs.
Reste a voir si le wifi ne perturbe pas les stats en générant des CongSignals...
J'en suis la pour le moment dans mes investigations.