{"id":45,"date":"2025-11-16T02:39:46","date_gmt":"2025-11-16T02:39:46","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=45"},"modified":"2026-11-06T22:04:21","modified_gmt":"2026-11-06T22:04:21","slug":"vps-network-verification-iperf3-mtr-disk-flush","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-network-verification-iperf3-mtr-disk-flush\/","title":{"rendered":"Verifying VPS Network Performance: iperf3, mtr and Disk Floor Checks"},"content":{"rendered":"\n

An iperf3<\/code> run that reports 9.4 Gbit\/s between two VPS instances in the same region tells you almost nothing about how a user in Frankfurt experiences your API. Single-stream throughput between two well-provisioned endpoints measures the least interesting path: no congestion, short RTT, large send buffers. The measurements that predict user experience are single-stream throughput over a realistic RTT, packet loss from mtr<\/code>, and the disk floor that limits what the network can deliver when data must be flushed to storage.<\/p>\n\n\n\n

This article is a verification checklist for a new instance: confirm the advertised network rate, find the real single-stream ceiling, read loss and jitter from mtr<\/code>, and establish the disk floor so that a network test is not secretly measuring storage.<\/p>\n\n\n\n

Baseline: Confirm the Interface and Link Speed<\/h2>\n\n\n\n

Before generating traffic, verify what the guest actually has. A virtio interface negotiates speed with the host, and while the host often virtualises the number, a mismatch in the guest is a genuine misconfiguration. Check the driver, ring sizes and offload state.<\/p>\n\n\n\n

ethtool eth0 | grep -E 'Speed|Duplex|Link detected'\nethtool -i eth0              # driver and firmware\nethtool -k eth0 | grep -E 'tso|gso|gro|checksum'\nethtool -S eth0 | grep -E 'tx_queue_stopped|rx_drops|tx_dropped'\nip -s link show eth0         # errors, dropped, overrun<\/code><\/pre>\n\n\n\n
Non-zero tx_queue_stopped<\/code> or growing dropped<\/code> on the interface counters during a test points at a queue limit rather than the network path. Raise net.core.txqueuelen<\/code> or check qdisc<\/code> state with tc -s qdisc show dev eth0<\/code>. Also confirm net.core.rmem_max<\/code> and net.ipv4.tcp_rmem<\/code> are large enough for a long-fat path; default 208 KiB receive windows cap single-stream throughput at roughly 25 Mbit\/s over 60 ms RTT.<\/p>\n\n\n\n
The bandwidth-delay product is the arithmetic that governs it: 1 Gbit\/s \u00d7 60 ms RTT needs about 7.5 MB in flight. Without tcp_wmem<\/code> and tcp_rmem<\/code> maxima near that value, no amount of link capacity helps.<\/p>\n\n\n\n
Multi-Stream vs Single-Stream iperf3<\/h2>\n\n\n\n
Run iperf3<\/code> in both modes and compare. Multi-stream saturates the link; single-stream reflects what one file transfer or one HTTP\/2 connection sees. The gap between them is where most “the network is slow” complaints live.<\/p>\n\n\n\n
# receiver\niperf3 -s\n\n# sender: 8 streams, 30 s\niperf3 -c 203.0.113.10 -t 30 -P 8\n\n# sender: naive single stream, 30 s\niperf3 -c 203.0.113.10 -t 30\n\n# sender: single stream with an 8 MB window (long-fat path)\niperf3 -c 203.0.113.10 -t 30 -w 8M --get-server-output\n\n# single stream in reverse (download direction)\niperf3 -c 203.0.113.10 -t 30 -R -w 8M\n\n# UDP test for loss and jitter at 1 Gbit\/s\niperf3 -c 203.0.113.10 -u -b 1G -t 20 --get-server-output<\/code><\/pre>\n\n\n\n
A healthy result looks like: 8 streams reaching near the provisioned rate, a single stream with an 8 MB window reaching 70\u201390% of the multi-stream figure, and the naive single stream with default window lower still. The UDP run reports lost packets at the receiver; more than 0.1% loss at a rate well below the provisioned cap indicates a problem, while loss at the cap is expected policing.<\/p>\n\n\n\n
Reading mtr for Loss and Route Changes<\/h2>\n\n\n\n
mtr<\/code> combines traceroute and ping, accumulating per-hop statistics. The mistake is reading loss at an intermediate hop as a problem; routers deprioritise ICMP to their own control plane, so loss at hop 4 with zero loss at hop 12 is usually reporting behaviour, not packet loss.<\/p>\n\n\n\n
mtr -rwzbc 100 203.0.113.10 | tee \/root\/mtr-out.txt\n# -r report, -w wide, -z ASN lookup, -b IPs, -c 100 cycles\n\n# compare both directions when you control both ends\nmtr -rwc 100 --tcp --port 443 target.example.com<\/code><\/pre>\n\n
Interpret as follows: loss that begins at a hop and persists to the destination is real; loss that appears at one hop and disappears later is ICMP rate limiting. High StDev<\/code> with low average on intermediate hops is jitter from control-plane processing. For a TCP service, run mtr --tcp --port 443<\/code> so the probes follow the same forwarding path as real traffic rather than the ICMP path, which can differ.<\/p>\n\n\n\n
Route asymmetry is common on cloud networks: the forward path may be three hops and the return path nine. Test from both ends if you can, and compare mtr<\/code> output from the user side against the server side. Where you cannot, a tracepath<\/code> run from the instance to the user’s network with tracepath -n target<\/code> gives the reverse view including MTU discovery results.<\/p>\n\n\n\n
Establishing the Disk Floor<\/h2>\n\n\n\n
Many network tests are accidentally disk tests. A scp<\/code> of large files, an HTTP upload to disk, or an iperf3<\/code> run writing to a file with --file<\/code> can be limited by storage. Measure the floor first so you know which number is the ceiling.<\/p>\n\n\n\n
# sequential write throughput\nfio --name=seqw --filename=\/mnt\/scratch\/net-floor --size=1G \\\n    --bs=1M --rw=write --direct=1 --ioengine=libaio --iodepth=8\n\n# sequential read throughput\nfio --name=seqr --filename=\/mnt\/scratch\/net-floor --size=1G \\\n    --bs=1M --rw=read --direct=1 --ioengine=libaio --iodepth=8\n\n# how long does an fsync of 64 MB take?\ndd if=\/dev\/zero of=\/mnt\/scratch\/flush-test bs=1M count=64 conv=fsync oflag=direct 2>&1 | tail -1<\/code><\/pre>\n\n\n\n
A 1 Gbit\/s link needs 125 MB\/s of sustained write to keep up; if the disk floor is 90 MB\/s, any receive-to-disk workload caps at 720 Mbit\/s regardless of network capacity. That is not a network fault, and filing it as one wastes time. Record the floor next to the network figures so future comparisons keep the two separate.<\/p>\n\n\n\n
Separating Storage Backend from Local Disk<\/h2>\n\n\n\n
On a VPS, the storage path often traverses the network too\u2014network block storage or a replicated volume. In that case the disk floor is itself network-sensitive, and network tests compete with disk traffic for the same NIC. Run them sequentially, never concurrently, and note the storage backend in your records.<\/p>\n\n\n\n
A quick way to see whether disk I\/O is traversing the network is to watch \/proc\/net\/dev<\/code> byte counters while running an fio<\/code> test with no other traffic. If interface counters climb in step with disk throughput, the volume is remote.<\/p>\n\n\n\n
A Repeatable Verification Sequence<\/h2>\n\n\n\n
Run the checks in a fixed order so results stay comparable across instances and across time. Order matters because later tests are sensitive to earlier load, and CPU contention from a previous benchmark skews the next one.<\/p>\n\n\n\n