Test your server’s network speed

Every server has its own 10 Gbps port. This guide shows how to measure it properly, why some tests show less, and what to send support if you suspect a problem. You need root access and either a second server or a nearby public iperf3 server.

What to expect

A 10 Gbps link carries at most about 9.4 Gbps of TCP data with standard 1,500-byte packets; protocol headers use the rest. Your port isn’t shared with anyone, but as on any network, the uplinks beyond it are. Real-world throughput therefore also depends on the route to the other end, and on the other end itself.

Why a single stream or a distant server shows less

A single TCP connection can’t send more than its window per round trip. At a 100 ms round-trip time, filling 10 Gbps takes 125 MB in flight, far beyond default Linux buffer limits. Each lost packet also slows a connection down for many round trips, and the effect grows with distance. Several parallel streams hide both limits.

Public test servers add limits of their own: many have a 1 or 10 Gbps port shared by everyone testing at that moment. A single-stream test to another continent tells you more about the path than about your port.

Test with iperf3

Install iperf3 with sudo apt install iperf3 or sudo dnf install iperf3. Pick a server near your location from the list of public iperf3 servers, note its port, and test both directions with eight parallel streams:

iperf3 -c <iperf-server> -p 5201 -P 8 -t 30 -O 3        # your server sends
iperf3 -c <iperf-server> -p 5201 -P 8 -t 30 -O 3 -R     # your server receives

-P 8 opens eight streams, -t 30 runs for 30 seconds, -O 3 discards the first three seconds while TCP ramps up, and -R reverses the direction. --bidir tests both directions at once.

iperf3 3.16 and later run each stream in its own thread. Older versions, such as those in Debian 12 and in AlmaLinux or Rocky Linux 9, handle all streams on one CPU core. If top shows iperf3 at 100% of a core, run two or three instances against different ports; many public servers accept a range such as 5200–5209.

Test between two of your servers

The cleanest test runs between two servers you control. On server A, start an iperf3 server that exits after one test; on server B, connect to it:

iperf3 -s -1                                  # on server A
iperf3 -c 203.0.113.10 -P 8 -t 30 -O 3        # on server B

Open TCP port 5201 in server A’s firewall for the test and close it afterward. Two servers in the same location test the ports themselves; servers in different locations test the path between them.

Test with Speedtest CLI

Speedtest by Ookla measures against servers run by internet providers worldwide. Install the official CLI from speedtest.net/apps/cli, not the older, unofficial speedtest-cli Python package. Then:

speedtest --accept-license -L          # list nearby servers
speedtest --accept-license -s 12345    # test against a server ID from that list

Speedtest servers vary widely in capacity, so try two or three before you draw conclusions.

Tune Linux for long-distance transfers

Larger TCP buffers let each connection keep more data in flight. Save these settings as /etc/sysctl.d/90-network-tuning.conf:

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.ipv4.tcp_mtu_probing = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Load them with sudo sysctl --system. The buffer sizes follow ESnet’s recommendations for 10 Gbps hosts on paths of up to 100 ms, and they apply to IPv6 too. BBR usually copes better with packet loss on long paths than CUBIC, the default; delete the last line to keep CUBIC. Check the result with sysctl net.ipv4.tcp_congestion_control.

Read the results

[SUM]   0.00-30.00  sec  32.8 GBytes  9.39 Gbits/sec  112             sender
[SUM]   0.00-30.00  sec  32.8 GBytes  9.38 Gbits/sec                  receiver

• Read the receiver line: it counts what actually arrived.
• The number after the rate on the sender line counts TCP retransmissions. Some are normal on internet paths; thousands combined with a low rate point to packet loss.
• Rates are in bits. Divide by 8 for bytes: 9.4 Gbit/s is about 1.17 GB/s.
• If results change with the time of day, or differ widely between targets, the limit lies on the path or at the far end, not at your port.

Report a problem

If tests between your own servers, or to several nearby targets, stay well below expectations, open a support ticket from your client area. Include:

• your server’s IP address and the test targets;
• the complete iperf3 commands and output, with the time of each test in UTC;
• an mtr report in both directions: from your server to the target, and from the target, or from your own network, back to your server.

mtr -rwbzc 100 <target-ip>

Install mtr with sudo apt install mtr-tiny or sudo dnf install mtr. Internet routing is often asymmetric: the return path can differ from the outbound one, so a single direction rarely tells the whole story. Loss that shows at one hop but doesn’t continue to the final hop is usually a router rate-limiting its own replies, not real packet loss.