Je speed-test liegt.
Meet liever responsiveness.

De leugen van het grote getal

Elke speed-test-site opent met een meter. Hij draait omhoog, blijft staan op een indrukwekkend getal (480 down, 510 down, 940 down als je glasvezel hebt) en dat getal wordt het verhaal. Het verhaal klopt bijna altijd niet. Niet oneerlijk, eigenlijk. Gewoon de verkeerde vraag, precies beantwoord.

Throughput is een meting van capaciteit: hoeveel water de buis kan verplaatsen als er niets anders gebeurt. Het probleem is dat echte netwerken er bijna nooit uitzien als „er gebeurt niets anders". Echte netwerken zien eruit als een gezinsvideogesprek, een cloudback-up, een Slack-sync, een software-update en een kind dat tekenfilms kijkt, allemaal tegelijk. In dat plaatje gaat het je niet om de totale liters per minuut. Het gaat je erom of jouw spraakpakketje voor de wachtrij langs kan en op tijd aankomt.

Die tweede vraag is responsiveness, en twintig jaar lang hadden we daar in een browser nauwelijks een meting voor. Nu wel. Hij zit in macOS. Alleen heeft niemand het je verteld.

Wat is bufferbloat, in één alinea

Elke router en modem tussen je laptop en het internet heeft een buffer: een beetje geheugen waar pakketten op hun beurt wachten. Als de link vóór de buffer langzamer is dan die erachter (jouw 40 Mbps uplink achter een gigabit-LAN bijvoorbeeld), begint de buffer vol te lopen. Fabrikanten hebben die buffers absurd groot gemaakt, omdat het laten vallen van pakketten op een bug lijkt. Maar een te grote buffer houdt jouw Zoom-spraakpakketje vast achter elk ander pakketje dat een milliseconde eerder binnenkwam. De buis verplaatst genoeg bytes. De bytes die ertoe doen, staan alleen in de rij. Die vertraging (gemeten in honderdtallen milliseconden onder belasting) is bufferbloat. Daarom slaagt je speed-test en valt je gesprek uiteen.

Daar is RPM: Round-trips Per Minute

In 2021 stelde Apple's netwerkteam een metric in gewone taal voor: RPM, oftewel Round-trips Per Minute. Het idee is bijna gênant simpel. Terwijl de buis verzadigd is (je downloadt en uploadt op volle kracht), tel hoeveel volledige verzoek/antwoord-rondes je in één minuut afkrijgt. Een responsief netwerk haalt er duizenden. Een bloated-netwerk zakt naar enkele honderden. Dezelfde 500-Mbps-buis in beide gevallen.

Apple leverde daarvoor een tool met macOS Monterey. Het heet networkQuality, staat op /usr/bin/networkQuality, en als je een Terminal opent en het draait, zie je zoiets als dit:

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

Lees die uitvoer aandachtig. De buis is dik, bijna een halve gigabit download. De responsiveness is medium. 540 round-trips per minuut zijn ongeveer negen per seconde: jouw spraakpakketje wacht op een belast netwerk ruwweg 111 ms, tegenover 18 ms in rust. Dat verschil is precies waarom je gesprek prima klinkt als er niemand thuis is en knapt als het hele gezin streamt.

High, Medium, Low, wat betekenen die?

Apple verdeelt RPM in drie leesbare categorieën:

• High, 2.000 RPM en hoger. Het netwerk is responsief. Realtime werk (gesprekken, gamen, samen bewerken) voelt knapperig, ongeacht wat er verder draait.
• Medium, ongeveer 600–2.000 RPM. Het netwerk is bruikbaar, maar interactieve apps voelen onder belasting traag aan. Hier zit het gros van de huisnetwerken in de spits, en hier komen de klachten vandaan.
• Low, onder de 600 RPM. De buffers zitten vol. Spraakgesprekken vallen weg, video bevriest, toetsaanslagen in een SSH-sessie komen in batches binnen. Geen extra bandbreedte ter wereld lost dit op tot de buffers leeg zijn.

Waarom een speed-test dit niet ziet

Een speed-test meet alleen de makkelijke helft van het probleem: idle throughput, meestal in een korte burst, meestal over een verbinding die je provider heeft leren bevoorrechten. Hij vertelt je wat je buis kan als hij licht belast is, en stelt nooit de vervolgvraag over latency onder belasting. Bufferbloat is per definitie onzichtbaar voor die test, want de test is de belasting, er is geen ander verkeer dat erachter in de rij staat.

Het symptoom aan de klantkant is bekend. De provider-monteur komt langs, draait de speed-test, hij slaagt, en je hoort dat de verbinding in orde is. Het volgende videogesprek hapert nog steeds. De monteur loog niet. Hij mat het verkeerde.

De RPM-test in de praktijk

Apple's networkQuality is elegant en meedogenloos. Het opent meerdere parallelle verbindingen naar CDN-eindpunten, verzadigt ze in beide richtingen en klokt vervolgens hoe snel een klein HTTP/2-verzoek/antwoord-paartje kan voltooien terwijl die verzadiging plaatsvindt. Dat is de RPM-waarde. De capaciteitsmetingen vallen er voor niets bij, daarom levert de tool met één run alle drie de getallen.

De test duurt een seconde of vijftien. Hij beukt op je lijn, dus draai hem niet tijdens een gesprek. Hij brengt ook dingen aan het licht die je provider liever niet laat zien: Wi-Fi-kanalen die met buren botsen, een router met een firmware-bug die de queue-diepte verdubbelt, een VPN die per round-trip 200 ms latency toevoegt. Heel vaak ontdek je dat de zwakke schakel niet je provider is. Het zit gewoon in jouw eigen huis.

Wat te doen als RPM Low is

Geen wondermiddel, maar de checklist is eindig:

1. Test eerst bedraad. Steek een Ethernet-kabel in de Mac en draai networkQuality opnieuw. Springt RPM naar High, dan zit je probleem in de Wi-Fi (drukte, kanaaloverlap of afstand), niet bij de provider.
2. Zet Smart Queue Management aan. Routers die SQM, CAKE of fq_codel ondersteunen, plat slaan bufferbloat dramatisch. Een router van $100 met fq_codel aan slaat een router van $600 zonder.
3. Beperk je upload. Is SQM niet beschikbaar, beperk de upload van de Mac dan tot ongeveer 90 % van de gemeten uplink-capaciteit. Alleen die wijziging zorgt dat je eigen uploads de buffer niet vullen en je downloads de retour-ACK's niet onthouden.
4. Vervang het modem-router-combinatieapparaat van de provider. Veel apparaten van providers staan ingesteld voor throughput-benchmarks, niet voor responsiveness. Het provider-apparaat in bridge-modus zetten en je eigen router ervoor plaatsen, is de grootste enkelvoudige RPM-verbetering die de meeste mensen zien.

Drie hardnekkige mythes

„Meer bandbreedte lost het op." Soms, meestal niet. Verzadigt je uplink al door één back-up, dan helpt opwaarderen van 40 naar 100 Mbps up. Maar als de schuldige de buffer is, sla je twee keer zo snel tegen hetzelfde plafond aan en de symptomen komen terug. De oplossing is de wachtrij legen, niet de buis ervoor verdikken.

„Mijn ping is 12 ms, dus het zit goed." Ping meet idle-latency: hoe lang een pakketje doet als er niets in de weg zit. Bufferbloat laat zich pas onder belasting zien. Een idle-ping van 12 ms op een bloated-link wordt onder belasting probleemloos 350 ms. Draai ping in één terminal en een grote upload in een andere, en je ziet het in realtime gebeuren.

„De provider heeft hier al voor geoptimaliseerd." Sommige wel. Veel niet. De engineering is niet moeilijk, maar de commerciële prikkel wijst de andere kant op: een netwerk dat is afgestemd op speed-tests wint markten waar op throughput-meters wordt gekocht. Responsiveness staat zelden op een marketingpagina.

Waar WiFi & IP Info inpast

We hebben de networkQuality-engine op één klik in de menubalk gezet. Het Network Quality-paneel van het Pro-niveau draait dezelfde Apple-test, toont uplink- en downlink-capaciteit, rapporteert het RPM-bucket en de basis-RTT, en, cruciaal, houdt een log bij. Een week lang ieder uur op „opnieuw uitvoeren" klikken, en je ziet het patroon: High op zaterdagochtend, Medium tijdens het avondeten, Low als de kinderen uit school komen. Die grafiek is wat de provider eindelijk in beweging krijgt, omdat reproduceerbaarheid een klacht in een ticket verandert.

Combineer het met de Latency History-grafiek en het Verbindingslogboek van de app, en je stuurt je provider een ticket dat je in dertig seconden schrijft: „RPM zakt tussen 18:00 en 21:00 lokaal van 2.400 naar 410, gecorreleerd met een drie keer hogere mediaan-RTT naar jullie eigen gateway. CSV bijgevoegd." Dat is een heel ander gesprek dan „mijn internet is langzaam."

De korte versie

Je speed-test meet capaciteit. Capaciteit is echt, en af en toe is dat het probleem. Meestal is het probleem echter responsiveness: of jouw verkeer er snel in en uit kan terwijl de buis bezet is. RPM is de metric daarvoor. Apple bouwde er een eersteklas tool voor. Wij zetten die tool in jouw menubalk en houden de geschiedenis bij.

Onthoud van deze pagina maar één zin: bandbreedte is hoe breed de weg is; responsiveness is hoe lang je voor het stoplicht staat. Beide doen ertoe. Slechts één van de twee staat op je speed-test-pagina.