Bandwidth Test
Bandwidth Test
Section titled “Bandwidth Test”Summary
Section titled “Summary”The Bandwidth Test tool measures network throughput between two MikroTik devices. It runs a client on one router and a server on another, generating traffic in one or both directions and reporting real-time throughput statistics. Use it to verify link capacity, identify bottlenecks, and validate QoS policy behaviour.
How It Works
Section titled “How It Works”One router acts as the server (passively accepts test connections) and the other acts as the client (initiates the test and reports results). The client connects to the server’s IP address, pushes or receives traffic for the specified duration, and then displays aggregate throughput.
Server Setup
Section titled “Server Setup”Enable the bandwidth-test server on the target router:
/tool/bandwidth-server set enabled=yesBy default the server requires authentication using the router’s user credentials. To allow unauthenticated tests:
/tool/bandwidth-server set enabled=yes authenticate=noFull server properties:
| Property | Default | Description |
|---|---|---|
enabled | no | Enable or disable the bandwidth server |
authenticate | yes | Require client to provide valid username/password |
allocate-udp-ports-from | 2000 | Starting port for UDP test sessions |
max-sessions | 100 | Maximum concurrent test sessions |
Running a Test
Section titled “Running a Test”From the client router, run /tool/bandwidth-test:
/tool/bandwidth-test address=192.168.88.1Core Parameters
Section titled “Core Parameters”| Parameter | Description |
|---|---|
address | IP address of the bandwidth server |
direction | Traffic direction: transmit, receive, or both (default: receive) |
protocol | Transport protocol: tcp or udp (default: tcp) |
duration | Test duration (e.g. 30s, 2m); 0s runs until interrupted |
user | Username for server authentication |
password | Password for server authentication |
connection-count | Number of parallel TCP/UDP connections (default: 20) |
random-data | Send random (incompressible) data; increases CPU load but defeats compression |
local-udp-tx-size | UDP payload size in bytes for local transmit (range: 28–64000; default: 1500); only affects direction=transmit or direction=both |
local-tx-speed | Limit local transmit speed (e.g. 100M) |
remote-tx-speed | Limit remote transmit speed |
Direction Values
Section titled “Direction Values”| Value | Meaning |
|---|---|
transmit | Client sends traffic to server |
receive | Server sends traffic to client |
both | Traffic flows in both directions simultaneously |
Examples
Section titled “Examples”Basic TCP Throughput Test
Section titled “Basic TCP Throughput Test”Test how fast the client can receive data over TCP:
/tool/bandwidth-test address=10.0.0.1 direction=receive protocol=tcp duration=30sBidirectional UDP Test
Section titled “Bidirectional UDP Test”Measure full-duplex UDP throughput simultaneously:
/tool/bandwidth-test address=10.0.0.1 direction=both protocol=udp duration=60sTest With Authentication
Section titled “Test With Authentication”/tool/bandwidth-test address=192.168.1.1 user=admin password=secret direction=transmit duration=30sMultiple Parallel Connections
Section titled “Multiple Parallel Connections”Increase connection-count to better saturate high-capacity links:
/tool/bandwidth-test address=10.0.0.1 direction=both protocol=tcp connection-count=10 duration=30sUDP With Custom Payload Size
Section titled “UDP With Custom Payload Size”Test transmit throughput with jumbo-frame-sized UDP payloads. local-udp-tx-size controls the local transmit packet size, so direction=transmit is required for it to take effect:
/tool/bandwidth-test address=10.0.0.1 protocol=udp direction=transmit local-udp-tx-size=9000 duration=30sTCP vs UDP: Choosing the Right Protocol
Section titled “TCP vs UDP: Choosing the Right Protocol”The protocol parameter controls how test traffic is generated. The two protocols serve different diagnostic purposes.
TCP uses flow control, congestion control, and retransmission. The measured rate reflects practical bulk-transfer throughput — similar to file transfers, SMB, or HTTP downloads over the link.
Use TCP when you want to answer: “How fast can my applications transfer data across this link?”
/tool/bandwidth-test address=10.0.0.1 protocol=tcp direction=both duration=30sUDP sends at a configured offered rate (local-tx-speed) without retransmission. The result shows whether the link can carry that load without dropping packets, exposing congestion, MTU issues, or queue behaviour under a controlled load.
Use UDP when you want to answer: “Does this link drop packets when loaded at a specific rate?” — particularly useful for validating QoS policies and wireless links.
/tool/bandwidth-test address=10.0.0.1 protocol=udp direction=transmit \ local-tx-speed=50M local-udp-tx-size=1400 duration=30sProtocol Comparison
Section titled “Protocol Comparison”| Characteristic | TCP | UDP |
|---|---|---|
| Retransmits lost packets | Yes | No |
| Flow / congestion control | Yes | No |
local-tx-speed (offered rate) | Optional cap | Target rate |
lost-packets counter meaningful | No | Yes |
| Reflects real application throughput | Yes | No |
| Best for QoS / queue validation | No | Yes |
Interpreting Results
Section titled “Interpreting Results”The test displays a continuously updated table during the run. Key output fields:
| Field | Description |
|---|---|
tx-current | Current transmit throughput (instantaneous sample) |
rx-current | Current receive throughput (instantaneous sample) |
tx-10-second-average | Rolling average TX over the last 10 seconds |
rx-10-second-average | Rolling average RX over the last 10 seconds |
tx-total-average | Average TX for the entire test — use this as the headline result |
rx-total-average | Average RX for the entire test |
lost-packets | Packets not received at the far end (meaningful in UDP tests) |
random-data | Whether random (incompressible) data mode is active |
local-cpu-load | CPU utilisation on the client router during the test |
remote-cpu-load | CPU utilisation on the server router during the test |
Reading the Numbers
Section titled “Reading the Numbers”tx-total-average is the most reliable result. The current and 10-second values show stability over time — large swings indicate an unstable path or CPU contention.
In TCP bidirectional tests, tx and rx rates often differ. This is expected: TCP acknowledgements flow in the opposite direction and consume some bandwidth, and flow control on each direction operates independently.
High lost-packets in UDP means the link or a queue is dropping packets at the offered rate. Reduce local-tx-speed until lost-packets drops to zero to find the link’s usable capacity for that traffic type.
High local-cpu-load or remote-cpu-load means the test is CPU-limited. The measured throughput reflects the device’s processing capacity, not the link’s physical capacity. On lower-end hardware, this is the most common cause of unexpectedly low results.
Example: suspicious low result tx-total-average: 45Mbps (expected 100Mbps) local-cpu-load: 98% ← CPU bottleneck, not the linkVerifying Link Capacity
Section titled “Verifying Link Capacity”Use this sequence to find a link’s practical capacity, ruling out CPU and configuration factors.
Step 1: Enable the server
Section titled “Step 1: Enable the server”On the remote router:
/tool/bandwidth-server set enabled=yes authenticate=yesStep 2: Run a TCP test
Section titled “Step 2: Run a TCP test”TCP gives a quick estimate of bulk-transfer throughput:
/tool/bandwidth-test address=<server-ip> user=admin password=<pass> \ protocol=tcp direction=both duration=30sCheck local-cpu-load and remote-cpu-load in the output. If either exceeds ~80%, add more parallel connections or reduce to single-direction to rule out CPU limits:
/tool/bandwidth-test address=<server-ip> user=admin password=<pass> \ protocol=tcp direction=transmit connection-count=1 duration=30sStep 3: Run a UDP test at the expected rate
Section titled “Step 3: Run a UDP test at the expected rate”To verify the link can carry a specific offered load without loss:
/tool/bandwidth-test address=<server-ip> user=admin password=<pass> \ protocol=udp direction=transmit local-tx-speed=100M \ local-udp-tx-size=1400 random-data=yes duration=30sA lost-packets count above zero means the link, a queue, or a device is dropping packets at that rate.
Step 4: Find the drop threshold
Section titled “Step 4: Find the drop threshold”Reduce local-tx-speed in 10% steps until lost=0. That rate is the link’s reliable UDP capacity for that packet size.
Validating QoS Policy Effectiveness
Section titled “Validating QoS Policy Effectiveness”Bandwidth Test is the most practical way to confirm that queue rules actually enforce priorities under congestion. The principle: generate deliberate overload, then observe whether queue statistics match the configured policy.
Basic QoS Test Procedure
Section titled “Basic QoS Test Procedure”1. Generate test traffic that matches a queue mark or interface.
Configure the test so traffic is classified by your existing Mangle/Queue rules. For example, if queue class video marks DSCP CS4:
# On client: run test to fill the link/tool/bandwidth-test address=10.0.0.1 user=admin password=<pass> \ protocol=udp direction=transmit local-tx-speed=110M duration=60s2. While the test is running, watch queue statistics on the router:
/queue simple print stats# or for queue tree:/queue tree print stats3. Verify that:
- High-priority queues show their allocated rate and low/zero drops.
- Low-priority queues are rate-limited and show drops or queued bytes.
- Total measured TX in bandwidth-test does not exceed the configured interface rate.
Example: Verifying a Simple Queue Limit
Section titled “Example: Verifying a Simple Queue Limit”# Queue limits 10.0.0.50 to 20Mbps/queue simple add name=client-limit target=10.0.0.50 max-limit=20M/20M
# Run test from 10.0.0.50 — server should see ~20Mbps not more/tool/bandwidth-test address=10.0.0.1 user=admin password=<pass> \ protocol=tcp direction=transmit duration=30s# Expected: tx-total-average ≈ 20Mbps despite link being fasterWatch queue counters during the test:
/queue simple print stats where name=client-limit# bytes-out grows; dropped > 0 confirms the shaper is activeLimitations and Caveats
Section titled “Limitations and Caveats”CPU Bottleneck
Section titled “CPU Bottleneck”Bandwidth Test runs in software on the router’s CPU. On low-end hardware, the test may saturate the CPU before saturating the link, producing lower-than-actual results. Run tests when the router is otherwise idle.
random-data and CPU Load
Section titled “random-data and CPU Load”When random-data=yes, the router generates non-compressible random data for each packet. This is more representative of real traffic but substantially increases CPU usage and typically reduces measured throughput compared to random-data=no.
Testing a Forwarding Router
Section titled “Testing a Forwarding Router”If you run Bandwidth Test on a router that is also forwarding production traffic, test results will reflect both forwarding overhead and test-generated load. Use a dedicated test path or test during low-traffic periods.
UDP Packet Loss
Section titled “UDP Packet Loss”UDP tests do not retransmit lost packets. High loss percentages in UDP tests indicate congestion, MTU mismatches, or hardware queuing drops — not a broken connection.
Hardware Offloading
Section titled “Hardware Offloading”Traffic generated by Bandwidth Test passes through the router’s CPU. Hardware-offloaded bridge or switch paths are not exercised, so results may not reflect true hardware forwarding throughput.
Related Resources
Section titled “Related Resources”- Torch - Real-time per-flow traffic inspection
- Interface Stats and Monitor Traffic - Interface counters and live rate monitoring
- Queue - Traffic shaping and QoS configuration