Testing your connection properly
Almost every “my port is slow” ticket turns out to be a measurement problem. Here is how to measure it so the number means something.
Why one stream is not enough
A single TCP connection over distance is limited by latency and window size long before it is limited by your port. At 30 milliseconds round trip, one stream often tops out at a few hundred megabit no matter how big the pipe is. That is TCP working as designed, not a fault.
Use several streams: iperf3 -c host -P 8. If eight streams together
fill the port, your port is fine and your single-stream test was the problem.
Test against something that can keep up
The far end has a port too, often a smaller one, and a public speed test server is shared with everybody else. A result is only as good as the slowest side. Where you can, test between two machines you control.
Check the link itself first
ethtool eth0 tells you what the interface actually negotiated. A
10 Gbit card sitting at 1 Gbit is a cable or a port setting, and that is ours to fix
— send us the output.
Disks lie about the network
Copying a file from a spinning disk will never fill a 10 Gbit port; the disk gives
up first. Test with iperf3, which generates traffic in memory, before
you conclude anything about the network.
When it is genuinely slow
Latency and loss that persist to the final hop point at the path, not the port. Send
us an mtr report in both directions and we will look at
it — see when the route is bad. Because the
routing is ours, that is usually something we can actually change.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base