Alles is traag in de avond

Overdag klopt alles. Tussen zeven en elf duurt het openen van een website twee tellen te lang, hapert een videogesprek en is gamen niet te doen, terwijl een snelheidsmeting nog steeds een redelijk getal geeft. Dat laatste is verwarrend, en het is tegelijk de belangrijkste aanwijzing.

Wat het niet is: als het de hele dag traag is, is dit niet je hoofdstuk. Als het alleen op wifi traag is en niet aan een kabel, lees dan Wifi is traag. Als alleen één dienst hapert, is het die dienst.

De snelle controles, op volgorde

1. Meet de vertraging terwijl het druk is, niet de snelheid. Laat een ping naar een vast adres doorlopen: /ping 1.1.1.1 count=100, eerst rustig, dan tijdens de spits. Een goed antwoord is een vertraging die nauwelijks beweegt. Springt hij van 10 ms naar 300 ms zodra er iemand downloadt, dan heb je bufferbloat, en dat is de meest voorkomende oorzaak van precies deze klacht.
2. Is je lijn echt vol? /interface monitor-traffic interface=ether1 op de WAN-poort. Zit je tegen je abonnement aan, dan is het antwoord simpel. Zit je op de helft terwijl alles stroperig voelt, dan is het geen bandbreedte maar wachtrij.
3. Wie gebruikt het? /tool torch interface=ether1 sorteert live op verbruik. Vaak is het één back-up, één spelupdate of één apparaat dat de rest verdringt.
4. Is de router zelf nog rustig? /system resource print. Boven de 80 procent CPU is de router de bottleneck en niet de lijn. Zie je dat, ga dan naar CPU op 100 procent.
5. Hoeveel verbindingen staan er open? /ip firewall connection print count-only. Tienduizenden verbindingen op een klein bordje kosten geheugen en tijd.
6. Doen je wachtrijen hun werk? Heb je QoS aanstaan: /queue simple print stats of /queue tree print stats. Tellers die niet bewegen betekenen dat het verkeer erlangs gaat.

De gewone oorzaken, meest voorkomende eerst

Bufferbloat

Je modem of de apparatuur van je provider heeft een grote buffer. Zodra iemand een upload start, vult die buffer zich en staat elk klein pakketje, elke DNS-vraag en elk spelletje achter in die rij te wachten. De snelheidsmeting blijft goed, want die meet doorvoer, en de vertraging is precies wat je voelt.

De oplossing is de wachtrij naar je eigen router halen. Zet een limiet op ongeveer 90 tot 95 procent van je werkelijke lijnsnelheid en laat CAKE of fq_codel de rij beheren. Je levert een paar procent snelheid in en je krijgt er een netwerk voor terug dat onder belasting nog reageert.

De lijn zit echt vol

Een gezin dat 's avonds vier streams tegelijk kijkt en ondertussen een console laat updaten, kan een aansluiting gewoon opmaken. Hier helpt eerlijk delen: dan gaat niemand onderuit doordat één apparaat alles pakt.

Eén apparaat verdringt de rest

Een back-up naar de cloud, een grote spelupdate of een synchroniserende fotomap gebruikt alles wat er is. Dat is geen storing, dat is een apparaat dat doet wat het moet. Een limiet per host lost het op.

Je wifi is in de avond ook drukker

Niet alleen jouw netwerk wordt 's avonds gebruikt, dat van de buren ook. Op 2,4 GHz merk je dat direct. Als de kabel wel snel blijft en de wifi niet, is dit het.

De uplink van de provider zelf

Kabelaansluitingen delen capaciteit in de wijk, en dat merk je op het uur waarop iedereen thuis is. Een ping naar de eerste hop buiten je router die ook oploopt terwijl jouw lijn niet vol zit, wijst die kant op.

Wat de configurator hieraan doet

• Het onderdeel QoS / bandbreedte heeft vier standen: uit, één totaallimiet, eerlijk delen per host met anti-bufferbloat, en prioriteiten via een queue tree. Voor deze klacht is eerlijk delen per host met CAKE het juiste antwoord. Zet je werkelijke download- en uploadsnelheid in de velden.
• De introductie van het onderdeel zegt waarom dat werkt: zet de limiet iets onder de werkelijke lijnsnelheid, ongeveer 90 tot 95 procent, zodat de router de wachtrij beheert in plaats van het modem.
• Kies je fq_codel of PCQ in plaats van CAKE, dan kan dat. PCQ heeft een extra veld voor een maximum per host.
• Met Limieten per host/netwerk geef je één adres of één subnet een eigen plafond en een prioriteit. Dat is de knop voor het apparaat dat de rest verdringt.
• De tool waarschuwt zodra QoS aanstaat: FastTrack wordt in de firewall uitgeschakeld, wat de CPU-belasting verhoogt, en op kleine routers kost dat doorvoer. Dat is geen bijwerking die je kunt vermijden: verkeer dat fasttracked is, slaat de wachtrij over.
• Kies je een queue tree met prioriteiten op een oudere router en vul je meer dan 200 Mbit/s in, dan zegt de tool het eerlijk: deze router shapet in software en haalt met FastTrack uit naar schatting 200 tot 300 Mbit/s, dus de CPU wordt waarschijnlijk de bottleneck en de prioriteiten kloppen dan niet meer. Met de aanbeveling erbij om dan eerlijk delen met CAKE of fq_codel te nemen.
• Teken je op het netwerkbord de internetsnelheid bij de internet-node, dan meldt de controle het als de poort waar de lijn op landt langzamer is dan het abonnement, en noemt hij een betere poort.

De eerlijke grens

Een wachtrij maakt je lijn niet breder. Als je abonnement in de avond structureel te klein is voor wat het huishouden doet, verdeelt QoS de schaarste netjes en meer niet. Wat er buiten je router gebeurt, is helemaal niet van jou: de capaciteit in de wijk, de knooppunten van je provider en de servers aan de andere kant van de verbinding zitten allemaal achter je WAN-poort. En de getallen die je in de QoS-velden zet, moet je zelf meten op een rustig moment: de tool weet niet wat jouw lijn werkelijk haalt.

Verder lezen: QoS en bandbreedte, Snelheid meten en Controles over snelheid.