Votre speed-test ment. Mesurez la responsiveness à la place.

Le mensonge du grand chiffre

Chaque site de speed-test ouvre sur une jauge. Elle s'élance, se pose sur un nombre impressionnant (480 down, 510 down, 940 down si vous êtes en fibre) et ce nombre devient le récit. Le récit est presque toujours faux. Pas malhonnête, exactement. Juste la mauvaise question, à laquelle on répond précisément.

Le débit est une mesure de capacité : combien d'eau le tuyau peut faire passer quand rien d'autre ne se passe. Le problème, c'est que les vrais réseaux ne ressemblent presque jamais à « rien d'autre ne se passe ». Les vrais réseaux ressemblent à un appel vidéo familial, une sauvegarde cloud, une synchro Slack, une mise à jour, et un enfant qui regarde des dessins animés, tout en même temps. Dans cette scène, ce qui vous importe n'est pas le total des litres par minute. C'est de savoir si votre paquet vocal peut couper la file et arriver à l'heure.

Cette deuxième question est la responsiveness, et pendant vingt ans nous n'avions presque aucun moyen de la mesurer dans un navigateur. Maintenant si. C'est intégré à macOS. On ne vous l'a simplement jamais dit.

Qu'est-ce que le bufferbloat, en un paragraphe

Chaque routeur et chaque modem entre votre ordinateur et internet possède un buffer : un peu de mémoire où les paquets attendent leur tour. Quand le lien devant le buffer est plus lent que celui derrière (votre uplink à 40 Mbps derrière un LAN gigabit, par exemple), le buffer commence à se remplir. Les fabricants ont rendu ces buffers démesurément gros, parce qu'une perte de paquets ressemble à un bug. Mais un buffer trop grand maintient votre paquet vocal Zoom derrière chaque autre paquet arrivé une milliseconde plus tôt. Le tuyau déplace plein d'octets. Les octets qui comptent attendent simplement dans la file. Ce délai (qui se compte en centaines de millisecondes sous charge) est le bufferbloat. C'est pour ça que votre speed-test passe et que votre appel s'effondre.

Voici RPM : Round-trips Per Minute

En 2021, l'équipe réseau d'Apple a proposé une métrique en clair : RPM, ou Round-trips Per Minute. L'idée est presque gênante de simplicité. Pendant que le tuyau est saturé (vous téléversez et téléchargez à fond), comptez combien d'allers-retours requête/réponse complets vous arrivez à boucler en une minute. Un réseau réactif en aligne des milliers. Un réseau bloated tombe à quelques centaines. Le même tuyau de 500 Mbps dans les deux cas.

Apple a livré l'outil correspondant dans macOS Monterey. Il s'appelle networkQuality, vit dans /usr/bin/networkQuality, et si vous ouvrez un Terminal et le lancez, vous verrez à peu près ceci :

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

Lisez attentivement cette sortie. Le tuyau est gros, près d'un demi-gigabit en download. La responsiveness est medium. 540 allers-retours par minute, c'est environ neuf par seconde : votre paquet vocal attend à peu près 111 ms sur un réseau chargé, contre 18 ms à vide. Cet écart est exactement la raison pour laquelle votre appel sonne bien quand personne d'autre n'est à la maison, et part en miettes quand toute la famille streame.

High, Medium, Low, ça veut dire quoi ?

Apple range RPM en trois catégories lisibles :

High, à partir de 2 000 RPM. Le réseau est réactif. Le travail temps réel (appels, jeu, édition collaborative) sera net, peu importe ce qui tourne d'autre.
Medium, environ 600–2 000 RPM. Le réseau reste utilisable, mais les applis interactives sembleront molles sous charge. C'est là que se trouvent la plupart des réseaux familiaux aux heures de pointe, et c'est de là que viennent les plaintes.
Low, en dessous de 600 RPM. Les buffers sont pleins. Les appels vocaux sautent, la vidéo se fige, les frappes dans une session SSH arrivent par paquets. Aucune bande passante supplémentaire n'arrange ça tant que les buffers ne se vident pas.

Pourquoi un speed-test ne voit pas ça

Un speed-test ne mesure que la moitié facile du problème : le idle throughput, en général en un court burst, en général sur une connexion que votre opérateur a appris à prioriser. Il vous dit ce que votre tuyau sait faire quand il n'est pas chargé, et ne pose jamais la question suivante sur la latence sous charge. Le bufferbloat est, par définition, invisible à ce test : le test est la charge, il n'y a pas d'autre trafic qui ferait la queue derrière.

Le symptôme côté client est familier. Le technicien de l'opérateur passe, lance le speed-test, ça passe, et on vous dit que la connexion va bien. L'appel vidéo suivant saute encore. Le technicien n'a pas menti. Il a mesuré la mauvaise chose.

Le test RPM en pratique

Le networkQuality d'Apple est élégamment brutal. Il ouvre plusieurs connexions parallèles vers des points CDN, les sature dans les deux sens, puis chronomètre le temps qu'une petite paire requête/réponse HTTP/2 met à se boucler pendant que la saturation a lieu. C'est la valeur RPM. Les mesures de capacité tombent en bonus, c'est pourquoi l'outil renvoie les trois chiffres en un seul lancement.

Le test dure une quinzaine de secondes. Il martèle votre lien, donc à ne pas lancer pendant un appel. Il révèle aussi des choses que votre opérateur préférerait ne pas vous montrer : des canaux Wi-Fi qui interfèrent avec les voisins, un routeur dont le firmware double la profondeur de file, un VPN qui ajoute 200 ms de latence à chaque aller-retour. Très souvent, vous découvrirez que le maillon faible n'est pas votre opérateur. C'est quelque chose chez vous.

Que faire quand le RPM est Low

Pas de balle d'argent, mais la liste est finie :

Testez en filaire d'abord. Branchez un câble Ethernet sur le Mac et relancez networkQuality. Si le RPM saute en High, le problème est le Wi-Fi (encombrement, recouvrement de canaux ou distance), pas l'opérateur.
Activez le Smart Queue Management. Les routeurs qui supportent SQM, CAKE ou fq_codel aplatissent radicalement le bufferbloat. Un routeur à 100 $ avec fq_codel battra un routeur à 600 $ sans.
Plafonnez votre upload. Si SQM n'est pas dispo, bridez l'upload du Mac à environ 90 % de la capacité d'uplink mesurée. Ce seul changement empêche vos propres uploads de remplir le buffer et d'affamer vos téléchargements en ACK.
Remplacez le combo modem-routeur de l'opérateur. Beaucoup d'unités fournies par les opérateurs sont réglées pour les benchmarks de débit, pas pour la responsiveness. Mettre l'unité opérateur en mode bridge et placer votre propre routeur devant est la plus grosse amélioration RPM en un coup que verront la plupart des gens.

Trois mythes tenaces

« Plus de bande passante va régler ça. » Parfois, le plus souvent non. Si votre uplink est déjà saturé par une seule sauvegarde, passer de 40 à 100 Mbps en up va aider. Mais si le coupable réel est le buffer, vous heurterez le même plafond deux fois plus vite et les symptômes reviendront. La solution, c'est vider la file, pas élargir le tuyau devant.

« Mon ping est à 12 ms, donc je vais bien. » Le ping mesure la latence à vide : combien de temps met un paquet quand rien n'est dans le chemin. Le bufferbloat n'apparaît que sous charge. Un ping à vide de 12 ms sur un lien bloated devient tranquillement un ping chargé de 350 ms. Lancez ping dans un terminal et un gros upload dans un autre, et vous verrez ça en temps réel.

« L'opérateur a déjà optimisé pour ça. » Certains, oui. Beaucoup, non. L'ingénierie n'est pas dure, mais l'incitation commerciale pointe dans l'autre sens : un réseau réglé pour le speed-test gagne les marchés qui achètent au compteur de débit. La responsiveness apparaît rarement sur une page marketing.

Où WiFi & IP Info trouve sa place

Nous avons placé le moteur networkQuality à un clic dans la barre de menus. Le panneau Network Quality du palier Pro lance le même test Apple, expose la capacité uplink/downlink, signale le palier RPM et la base RTT, et, surtout, garde un journal. Vous pouvez cliquer sur « relancer » une fois par heure pendant une semaine et voir le motif : High le samedi matin, Medium au dîner, Low quand les enfants rentrent de l'école. C'est ce graphique qui pousse l'opérateur à faire quelque chose, parce que la reproductibilité est ce qui transforme une plainte en ticket.

Combinez avec le graphique d'Historique de latence de l'app et le Journal des connexions, et vous envoyez à votre fournisseur un ticket de trente secondes : « RPM tombe de 2 400 à 410 entre 18:00 et 21:00 heure locale, corrélé avec un RTT médian trois fois plus haut vers votre propre passerelle. CSV ci-joint. » C'est une conversation très différente de « mon internet est lent. »

La version courte

Votre speed-test mesure la capacité. La capacité est réelle, et de temps en temps c'est elle le problème. La plupart du temps, en revanche, le problème est la responsiveness : votre trafic peut-il entrer et sortir rapidement pendant que le tuyau est occupé. RPM est la métrique pour ça. Apple a construit un outil de premier plan pour la mesurer. Nous avons mis cet outil dans votre barre de menus, et nous gardons l'historique.

Si vous ne deviez retenir qu'une phrase de cette page, retenez celle-ci : la bande passante, c'est la largeur de la route ; la responsiveness, c'est le temps que vous passez aux feux. Les deux comptent. Une seule des deux est sur votre page de speed-test.