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 ?

Effectivement ce 2eme graphe me met le doute sur la compréhension des datas maintenant 
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.

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:



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.