Test network speed and routes: iperf3, mtr and curl

“The network is slow” can mean low throughput, high latency, jitter or packet loss, and the cause can sit on your server, on the remote end or anywhere in between. The tools below tell these apart. Install them first.

Ubuntu and Debian (when asked whether to start iperf3 as a daemon, answer No):

apt install -y iperf3 mtr-tiny curl

AlmaLinux and Rocky Linux

dnf install -y iperf3 mtr curl

What speeds to expect

A port speed is the raw line rate. Ethernet framing and the IP and TCP headers use part of it, so with the standard 1500-byte MTU the best possible TCP payload rate is about 94% of the port speed:

So 940 Mbit/s on a 1 Gbps port means the link is full, not underperforming. Reaching that speed to a given destination also depends on the remote server, its own port and the path in between, and 10 Gbps usually needs several parallel streams. Bandwidth on DediJet ports is unmetered, so tests cost nothing extra (see unmetered bandwidth explained). Plans with a 1 Gbps port can be upgraded to 10 Gbps for $129/mo; see add-ons.

Measure throughput with iperf3

iperf3 measures raw TCP or UDP throughput between two machines you control, without disks or web servers in the way. The cleanest test runs between two of your own servers: over the public network, or over the free private VLAN, available on request, if they are in the same location.

Run a test

On the receiving server, open the port and start a one-off server that exits after one test:

ufw allow 5201/tcp
iperf3 -s -1

With firewalld, use firewall-cmd --add-port=5201/tcp; without --permanent, the rule disappears at the next reload. Then, on the other server, run one of these, restarting iperf3 -s -1 before each:

iperf3 -c 203.0.113.20 -t 30
iperf3 -c 203.0.113.20 -t 30 -R
iperf3 -c 203.0.113.20 -t 30 -P 4

The first sends from the client to the server, -R reverses the direction, and -P 4 runs four parallel streams. Remove the firewall rule afterwards with ufw delete allow 5201/tcp.

Read the results

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  3.28 GBytes   939 Mbits/sec   12             sender
[  5]   0.00-30.04  sec  3.28 GBytes   938 Mbits/sec                  receiver

This illustrative output shows a saturated 1 Gbps link. The receiver line is what actually arrived. Retr counts TCP retransmissions: a handful is normal, thousands point to loss or congestion on the path.

• One stream slow, four streams fast: a per-stream limit, such as the TCP window over a long distance. One stream needs a window of bandwidth × round-trip time: 1 Gbit/s × 150 ms ≈ 19 MB, more than default Linux settings allow.
• Fast in one direction only: compare the runs with and without -R. A one-way problem is useful information for a ticket.
• 10 Gbps tests: iperf3 versions before 3.16 run all streams on one CPU core, which can become the bottleneck. Check with iperf3 --version, or start several iperf3 processes on different ports with -p.

Public iperf3 servers exist, but they are shared and often busy: their results say more about their load than about your server. To measure CPU, memory and disks rather than the network, see Benchmark your server.

Time a real download with curl

To test a real HTTP path, download a large file to /dev/null, so the disk is not involved, and let curl report the numbers:

curl -o /dev/null -s -w 'speed: %{speed_download} B/s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n' https://mirror.example.com/large-file.iso

Use a large file on a well-connected server near the destination you care about, such as an ISO image from your distribution’s mirror list. speed_download is in bytes per second: 117,000,000 B/s is about 940 Mbit/s. One download is limited by the remote server and its connection, so compare several sources before drawing conclusions. Add -4 or -6 to compare IPv4 and IPv6; if IPv6 fails entirely, check your IPv6 configuration.

Latency and jitter with ping

ping -c 100 -i 0.2 203.0.113.20

100 packets transmitted, 100 received, 0% packet loss, time 19804ms
rtt min/avg/max/mdev = 11.204/11.391/12.877/0.214 ms

avg is the typical round-trip time, and mdev, the standard deviation, is a practical measure of jitter. For game servers and voice, stable latency matters more than raw bandwidth: look for a low mdev and 0% loss. The figures on our latency checker are estimates computed from distance, so measured values on a real route can differ.

Find where it breaks: mtr and traceroute

mtr combines traceroute and ping: it probes every hop on the path, over and over. Run it in report mode with enough cycles to be meaningful:

mtr -rwbz -c 100 203.0.113.20

-r prints a report, -w keeps hostnames whole, -b shows names and IP addresses, -z adds the AS number of each hop, and -c 100 sends 100 probes per hop.

HOST: web1                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS64500  198.51.100.1       0.0%   100    0.4   0.5   0.3   1.9   0.2
  2. AS64500  198.51.100.9      38.0%   100    1.3   4.9   1.0  48.2   9.1
  3. AS64501  192.0.2.17         0.0%   100    7.9   8.1   7.8   9.4   0.2
  4. AS64501  203.0.113.20       0.0%   100    8.3   8.4   8.1  10.2   0.3

How to read it

• Only loss that reaches the last hop counts. Hop 2 shows 38% loss, but hops 3 and 4 show none: that router rate-limits the replies it generates itself, which is common and harmless. Real loss starts at one hop and continues on every hop after it, down to the destination.
• Latency works the same way. A spike on one middle hop that does not carry on to later hops means that router is slow to answer, not slow to forward.
• Routes are often asymmetric. The return path can cross other networks, so an mtr from your server shows only half the picture. Run one in the opposite direction too.
• ICMP filtered? Probe with TCP to an open port instead: mtr -rwbz -T -P 443 -c 100 example.com.

Without mtr, traceroute -n 203.0.113.20 (from the traceroute package) lists the hops once, and tracepath needs no root and also reports the path MTU.

When to open a ticket

Check the status page first. Then open a ticket from Support if you see packet loss that continues to the destination, throughput far below the figures above between two well-connected machines, or a problem that started at a specific time. Include:

• The server’s IP address and the remote address you tested against.
• mtr reports in both directions, from your server to the destination and from the destination or the affected user back to your server, with at least 100 cycles each.
• Your iperf3 or curl results, the time of the tests with its time zone, and whether IPv4, IPv6 or both are affected.
• Whether the problem is constant or intermittent, and when it started.

A network outage is handled as critical, with a first-response target of 30 minutes; other tickets have a first-response target of 4 hours. If you suspect an attack, read DDoS protection first.