De klant zegt dat het traag is. Voordat je iets gaat veranderen moet je weten waar het traag is, en dat is het lastige deel: elke meting meet iets anders, en vrijwel elke meting meet meer dan je denkt.
Tussen twee RouterOS-apparaten
RouterOS heeft een eigen meting die niet over internet gaat: de bandwidth test. Eén kant draait de server, de andere kant start de test. In Beheertoegang staat daarvoor de schakelaar Bandwidth-test server, standaard uit. Zet hem aan op het apparaat dat je wilt meten, en daarna weer uit.
Vanaf de andere kant:
/tool bandwidth-test address=192.168.88.1 direction=both protocol=udp user=admin password=…Drie dingen waar je op moet letten, en ze verklaren de meeste rare uitkomsten.
- De test kost CPU. Op een klein apparaat meet je de processor van de router, niet de lijn ertussen. Kijk tijdens de meting mee met
/system resource monitor; zit de CPU op honderd procent, dan is je getal de grens van het apparaat en niet van het netwerk. - UDP en TCP meten iets anders. UDP pompt zo hard als je opgeeft en laat zien wat de lijn draagt. TCP laat zien wat een gewone verbinding eruit haalt, inclusief de gevolgen van pakketverlies.
- Zet de server daarna uit. Een bandwidth-test server die open blijft staan is een manier om iemands netwerk plat te leggen.
Op recentere v7-versies is er daarnaast /tool speed-test, die ook naar een gewoon adres kan meten en er de latency bij zet. Handig voor een snel beeld; voor een echte meting tussen twee MikroTiks is de bandwidth test nog steeds preciezer.
Wat een speedtest in de browser meet
Een speedtest op een website meet de hele keten, van het toetsenbord tot de meetserver. In die keten zitten minstens deze schakels:
- de laptop of telefoon zelf, inclusief zijn netwerkkaart en zijn drukte;
- de wifi of de kabel naar de switch;
- de switch en de router, met NAT, firewall en eventuele queues;
- de aansluiting van je provider;
- het pad naar de meetserver en de drukte daar.
Als het getal tegenvalt, weet je dus nog niets over welke schakel het was. Wat wel helpt: meet met een kabel in plaats van wifi, meet vanaf twee verschillende apparaten, en meet een keer op een rustig moment. Wijkt kabel sterk af van wifi, dan is het wifi en hoef je niet verder in de router te kijken. Zie Wifi nameten.
Een tweede valkuil is de eenheid. Een aansluiting wordt verkocht in megabit per seconde, een download in je browser telt in megabyte per seconde. Dat scheelt een factor acht, en dat is de helft van alle klachten over trage downloads.
Waar de bottleneck meestal zit
In volgorde van hoe vaak wij het tegenkomen:
- Wifi. Verreweg de meeste. Een 5 GHz-verbinding met twee streams op 80 MHz haalt in de praktijk een fractie van wat het onderhandelde tarief belooft, en op 2.4 GHz in een flat kom je zelden boven de vijftig megabit.
- De poort waar het modem in zit. De tool kent de snelheid van elke poort op elk model en waarschuwt als je gigabitaansluiting in een 100 Mbit-poort zit, met de poort erbij waar hij wel thuishoort. Zie Controles over snelheid.
- De CPU van de router. Zonder fasttrack, of met queues aan, doet een klein apparaat het routeren in software. Een hAP of hEX haalt dan een paar honderd megabit en niet meer.
- De kabel. Een gigabitpoort die op honderd megabit gaat draaien is bijna altijd een kabel of een stekker. Zie Kabels en voeding.
- De andere kant. Soms is de server traag of het pad ernaartoe druk, en is er aan jouw kant niets aan de hand.
Kijk tijdens een meting op de interface zelf, dan zie je meteen waar het verkeer loopt en hoeveel:
/interface monitor-traffic ether1
/interface ethernet print statsDie tweede laat ook fouten en overruns zien. Een teller die oploopt is een aanwijzing die een speedtest je nooit geeft.
Wat fasttrack en queues met de cijfers doen
Dit is de belangrijkste reden dat hetzelfde apparaat de ene keer gigabit haalt en de andere keer de helft.
FastTrack staat in Firewall standaard aan. Het geeft bekende, lopende verbindingen een kortere weg door de router: langs de firewallregels en langs de queues heen. Dat is precies wat kleine apparaten gigabit laat halen, en precies waarom een queue dat verkeer niet ziet.
Zet je QoS aan, dan zet de tool fasttrack uit, want anders zou je shaping op het grootste deel van je verkeer niet werken. Je krijgt daar ook een waarschuwing over. Het gevolg is meetbaar: meer CPU, en op een klein apparaat een lagere piek. Dat is geen fout in de configuratie, het is de prijs van prioriteiten.
Daar hoort een tweede waarschuwing bij die de tool geeft als je een snelle lijn op een klein apparaat wilt shapen: een queue-boom die het niet bijhoudt prioriteert niet, die laat willekeurig vallen. Eén eerlijke wachtrij met CAKE of fq_codel doet op zo'n router meer goed dan een boom vol prioriteiten.
Wil je weten wat je apparaat zonder queues kan, meet dan met QoS uitgezet en fasttrack aan. Dat is je bovengrens. Wat je daarna met queues meet is altijd lager, en dat hoort zo.
Wat de tool hier niet doet
De configurator meet niets. Hij draait in je browser en praat niet met je apparaten. Wat hij wel doet is de bandwidth-test server aan- of uitzetten, waarschuwen als een poort langzamer is dan de lijn die erop zit, en waarschuwen als je shaping vraagt die het apparaat niet aankan. Het meten zelf doe je op de router.
Wil je het verloop over de tijd zien in plaats van één getal, zet dan Grafieken aan in Diensten en tools. Je krijgt dan /graphs met interfaces, CPU en queues. Voor serieuze monitoring is SNMP naar een eigen systeem de betere weg.
Verder lezen: QoS, Controles over snelheid en Kabels en voeding.