Measuring

The customer says it is slow. Before you change anything you need to know where it is slow, and that is the hard part: every measurement measures something different, and almost every measurement measures more than you think.

Between two RouterOS devices

RouterOS has a measurement of its own that does not go over the internet: the bandwidth test. One side runs the server, the other side starts the test. Management access has the switch for it, bandwidth test server, off by default. Turn it on for the device you want to measure, and off again afterwards.

From the other side:

/tool bandwidth-test address=192.168.88.1 direction=both protocol=udp user=admin password=…

Three things to watch, and they explain most odd results.

• The test costs CPU. On a small device you are measuring the router's processor, not the line between. Watch along during the measurement with /system resource monitor; if the CPU sits at a hundred percent, your number is the limit of the device and not of the network.
• UDP and TCP measure different things. UDP pushes as hard as you tell it to and shows what the line carries. TCP shows what an ordinary connection gets out of it, packet loss included.
• Switch the server off afterwards. A bandwidth test server left open is a way to flatten someone's network.

On recent v7 versions there is also /tool speed-test, which can measure towards an ordinary address and reports latency alongside. Useful for a quick picture; for a real measurement between two MikroTiks the bandwidth test is still the more precise one.

What a browser speed test measures

A speed test on a website measures the whole chain, from the keyboard to the measuring server. That chain has at least these links:

1. the laptop or phone itself, its network adapter and how busy it is;
2. the Wi-Fi or the cable to the switch;
3. the switch and the router, with NAT, firewall and any queues;
4. your provider's line;
5. the path to the measuring server and how busy that is.

So when the number disappoints, you still know nothing about which link it was. What does help: measure over a cable instead of Wi-Fi, measure from two different devices, and measure once at a quiet moment. If the cable differs sharply from Wi-Fi it is Wi-Fi, and you do not have to look further into the router. See Checking Wi-Fi afterwards.

A second trap is the unit. A line is sold in megabits per second, a download in your browser counts in megabytes per second. That is a factor of eight, and it is half of all complaints about slow downloads.

Where the bottleneck usually sits

In the order we meet them:

• Wi-Fi. By far the most common. A 5 GHz link with two streams on 80 MHz gets a fraction of what the negotiated rate promises, and on 2.4 GHz in a block of flats you rarely pass fifty megabits.
• The port the modem is in. The tool knows the speed of every port on every model and warns when your gigabit line sits in a 100 Mbit port, naming the port it belongs in. See Checks about speed.
• The router's CPU. Without fasttrack, or with queues on, a small device routes in software. A hAP or hEX then manages a few hundred megabits and no more.
• The cable. A gigabit port that comes up at a hundred megabits is nearly always a cable or a plug. See Cables and power.
• The other end. Sometimes the server is slow or the path to it is busy, and nothing is wrong on your side.

Look at the interface itself during a measurement and you see straight away where the traffic goes and how much:

/interface monitor-traffic ether1
/interface ethernet print stats

That second one also shows errors and overruns. A counter that climbs is a clue a speed test never gives you.

What fasttrack and queues do to the numbers

This is the main reason the same device reaches gigabit one time and half of it the next.

FastTrack is on by default in Firewall. It gives known, running connections a shortcut through the router: past the firewall rules and past the queues. That is exactly what lets small devices reach gigabit, and exactly why a queue cannot see that traffic.

Switch QoS on and the tool turns fasttrack off, because otherwise your shaping would not apply to most of your traffic. You get a warning about it too. The consequence is measurable: more CPU, and on a small device a lower peak. That is not a mistake in the configuration, it is the price of priorities.

A second warning belongs with it, which the tool gives when you try to shape a fast line on a small device: a queue tree that cannot keep up does not prioritise, it drops at random. One fair queue with CAKE or fq_codel does more good on such a router than a tree full of priorities.

If you want to know what your device can do without queues, measure with QoS off and fasttrack on. That is your ceiling. Whatever you measure afterwards with queues is lower, and that is as it should be.

What the tool does not do here

The configurator measures nothing. It runs in your browser and never talks to your devices. What it does do is switch the bandwidth test server on or off, warn when a port is slower than the line plugged into it, and warn when you ask for shaping the device cannot manage. The measuring itself happens on the router.

If you want the trend over time instead of one number, switch on graphing in Services and tools. You then get /graphs with interfaces, CPU and queues. For serious monitoring, SNMP into a system of your own is the better route.

Read on: QoS, Checks about speed and Cables and power.