Your VPS feels slow from home, a visitor abroad says pages crawl, or a speed test shows a fraction of the 1 Gbps you expected. Is it the server, the route or your own connection? One number from one tool can't tell you. Latency, loss and throughput are separate measurements, each depends on both ends and the path between them, and all three change during the day. Here is how to measure them on Ubuntu 24.04 and Debian 12.
Quick answer: Measure between machines you control, in both directions. For latency and loss, send 100 pings and run an mtr report from your computer to the VPS and from the VPS back to you; judge the loss at the last hop and the worst times, not only the average. For throughput, run iperf3 -s on the VPS and iperf3 -c from a second machine, then repeat with -R (the VPS sends) and -P 4 (four streams). Test at busy and at quiet hours. A speed test to a nearby Ookla server only shows that the port works. A 1 Gbps port tops out at about 949 Mbit/s of TCP, roughly 119 MB/s.
What Each Test Measures
| Tool | Measures | Blind spot |
|---|---|---|
ping | Round trip time and loss to one address | Hosts that ignore or rate limit ping |
mtr | Time and loss at every hop of the route | One direction per report |
iperf3 | TCP or UDP throughput between two machines that run it | Needs a second machine |
| Ookla Speedtest CLI | Download, upload and latency to a nearby test server | The route to your users |
Step 1: Install the Tools
Install them on the VPS and on the Linux machine you test from. On a Space-Node VPS you have full root access on KVM, so you can run everything here yourself.
sudo apt update
sudo apt install iperf3 mtr-tiny iputils-ping
When the iperf3 package asks "Start Iperf3 as a daemon automatically?", keep the default, No: you start the server by hand while you test. The mtr-tiny package gives mtr's helper raw network access during installation, so mtr runs without sudo. Ubuntu 24.04 ships iperf3 3.16, which runs a thread per stream, and Debian 12 ships the single threaded 3.12. The iperf3 FAQ says one thread only became the bottleneck above about 25 Gbps, so both are fine at 1 Gbps.
Step 2: Measure Latency and Loss With ping
From your computer, send 100 pings to the VPS. 203.0.113.10 is an example address; use your server's.
ping -c 100 203.0.113.10
After about 100 seconds, ping prints the packet loss and the minimum, average, maximum and mdev round trip times. The ping manual calls mdev "essentially an average of how far each ping RTT is from the mean RTT" and warns that high variability slows bulk transfers and gives "middling to poor VoIP quality". A low average with a high maximum and mdev is a different problem from a steady but high average.
Then ping from the VPS to what it talks to, such as your own connection or an API it depends on. Add -4 or -6 to test IPv4 and IPv6 separately, because visitors can arrive over either. On Windows, use the tools in our guide to testing ping to a Mumbai Minecraft server.
Step 3: Trace the Route Both Ways With mtr
Ping shows that something is slow or lossy; mtr shows where. From your computer:
mtr -rwbzc 100 203.0.113.10
-r prints a report, -w keeps host names whole, -b adds the IP addresses, -z adds the AS number of each hop's network, and -c 100 runs 100 cycles of one second. The columns are Loss%, Snt, Last, Avg, Best, Wrst and StDev.
Then the other direction. On the VPS, the first address in $SSH_CONNECTION is the one you connected from:
echo "$SSH_CONNECTION"
mtr -rwbzc 100 198.51.100.7
Akamai's MTR guide calls mtr "essentially a directional tool": packets "can take completely different routes to and from a particular destination", so collect a report each way. If your home router doesn't answer pings, the reverse report ends in 100% loss; read the hops before it. Following the same guide:
- Loss at one hop in the middle, 0% after it: that router rate limits its own replies but forwards your traffic fine. The guide's rule: "always trust the reports from later hops".
- A jump in Avg at one hop that is gone at the next: the same rate limiting, which "can also create the appearance of latency".
- Loss or a higher Avg that lasts from one hop to the last line: real loss, or a long or slow stretch of the route, begins there. The AS numbers show whose network it is.
If something on the way drops ping, mtr -T -P 443 -rwbzc 100 203.0.113.10 probes with TCP SYN packets instead; use a port your server listens on.
Step 4: Measure Throughput With iperf3
iperf3 measures what a path carries between two machines that run it. The best second machine is a server near your users; from home, your own line caps the result. On the VPS:
sudo ufw allow 5201
iperf3 -s
5201 is iperf3's default port: TCP for the control connection and TCP tests, UDP for UDP tests. ufw allow 5201 opens both, as the ufw manual shows for port 53; skip that line if you don't use UFW. From the second machine:
iperf3 -c 203.0.113.10 -t 30 -O 3 # the second machine sends
iperf3 -c 203.0.113.10 -t 30 -O 3 -R # the VPS sends
iperf3 -c 203.0.113.10 -t 30 -O 3 -R -P 4 # the VPS sends, four streams
By default the client sends. -R makes the VPS send, the direction of your visitors' downloads. -t 30 runs 30 seconds instead of the default 10, -O 3 adds a 3 second warm-up that iperf3 marks (omitted), "to skip past the TCP slow-start period", and -P 4 runs four streams. Read the sender and receiver lines at the end, or the [SUM] lines with -P. Retr counts the segments the sender had to send again, a sign of lost packets.
| What you see | What it points to |
|---|---|
| One stream slow, four streams much faster | A limit per connection: distance and TCP buffers, or loss |
| Every run equally slow | A fixed limit: your home line, the second machine or the port |
| The VPS sends slowly but receives fine | The VPS side or the route from it: check the mtr report from the VPS |
Voice chat and many games use UDP, where loss and jitter at a steady rate matter more than top speed:
iperf3 -c 203.0.113.10 -u -b 50M -t 30 -R
UDP tests send 1 Mbit/s unless you set -b, so set it below what the slower end can take. Read Jitter and Lost/Total Datagrams on the receiver line; for unexpected UDP loss, the iperf3 FAQ suggests adding -w 2M.
Stop the server with Ctrl+C and close the port with sudo ufw delete allow 5201. If the client reports unable to connect to server, the server isn't running or the port is closed. A server busy with someone else's test replies the server is busy running a test.
Step 5: Know What a Speed Test Shows
Ookla's Speedtest CLI measures the connection "between the client and a nearby Speedtest Server". From a VPS that server usually sits near the data center, so a good result proves the port works, not the route to a visitor in another country.
The documentation in Ookla's download allows use only "for personal, non-commercial use, through a command line interface on a personal computer", so it isn't meant for company servers. If your use fits: on 31 October 2026 Ookla's apt repository had a package for Debian 12 but none for Ubuntu 24.04, so use the Linux download from Ookla's CLI page, which needs no repository:
curl -sLO https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-x86_64.tgz
tar -xzf ookla-speedtest-1.2.0-linux-x86_64.tgz speedtest
./speedtest -L # the nearest servers and their IDs
./speedtest -s 12345 # test against one of them
Test against three or four servers from the list; if the results differ a lot, the test servers are the limit, not your VPS. Version 1.2.0 also shows the latency during the download and upload. When that is far above the idle latency, a queue on the path fills up under load.
The speedtest-cli package in Ubuntu and Debian is an unofficial Python tool. Its last release, 2.1.3, is from April 2021, its GitHub repository is archived, and its README says its latency "should not be relied on".
Step 6: Test at Different Times
A test at 10:00 says little about 21:00. Akamai's guide notes that congestion, "particularly over long distances during peak times, can become severe". Run ping, mtr and iperf3 at your users' busy hours and at a quiet hour, from the same machines, and note the date, time zone, direction and IP version with each result.
For route reports over a few days, add an hourly line with crontab -e on the VPS:
0 * * * * /usr/bin/mtr -rwbzc 100 198.51.100.7 >> "$HOME/mtr-hourly.txt" 2>&1
cron sets HOME from your user account, and every mtr report starts with a Start: line holding the date and time. Remove the line after a few days: the mtr manual warns that each running instance "generates a significant amount of network traffic". Don't schedule iperf3 this way: a 30 second run at 949 Mbit/s moves about 3.6 GB, which can count toward your monthly traffic.
What a 1 Gbps Port Means in Practice
The port speed is the most your VPS can send or receive in total, across all its connections. You reach it only when nothing slower sits on the path:
- Headers take a share. RFC 6349, the IETF framework for TCP throughput testing, puts the maximum TCP throughput over 1 Gbps Ethernet with standard 1,500 byte packets at 949.2 Mbit/s. An iperf3 result in the low 900s is a full port.
- Bits are not bytes. Ookla's documentation divides bytes per second by 125,000 to get Mbit/s, so 949 Mbit/s is about 119 MB/s in a browser or a file copy.
- The slowest link wins. ESnet's tuning guide describes end to end capacity as "the bandwidth of the slowest hop in your path". For most visitors that is their own connection: on a 100 Mbit/s line they download at 100 Mbit/s at best, from any server.
- Distance limits a single connection. TCP needs buffers of at least the bandwidth times the round trip time; ESnet's example is 6.25 MB for a 50 ms path at 1 Gbps. Linux tunes its buffers automatically, but ESnet notes that the default maximums are still too small for many fast paths. So one stream over a long distance can stay well below the port speed while four streams fill it.
Port speed and monthly traffic are separate limits; our guide to what a VPS price includes explains both. How much distance adds to latency between cities is covered in our guide to latency and server location and our connectivity overview, which use public ping tables.
If the Numbers Still Look Wrong
- Bad from your home only: test from a second server. If that is fine, the cause is your line or your provider's route, and your mtr report shows where.
- Bad from everywhere, both ways, at every hour: watch
topon both machines during an iperf3 run. If iperf3 keeps a core at 100%, the CPU is the limit; our guide to shared and dedicated vCPUs explains steal time (st). Also check that no backup job used the port at the time. - Trouble that starts in a network in between: Akamai's guide says "most issues will clear up by themselves within 24 hours", so test again the next day.
- Trouble that starts near the VPS and runs to the last hop: send your host both mtr reports as text, the iperf3 output with and without
-R, and the times with time zone. At Space-Node, human support answers live chat, Discord and email from 08:00 to 20:00 UTC.
FAQ
Can I run iperf3 from a Windows PC?
Not officially. The iperf3 FAQ lists Linux, FreeBSD and macOS and recommends iperf2 for other platforms. iperf2 and iperf3 can't test against each other, so use iperf2 at both ends: install the iperf package on the VPS, run iperf -s and open its default port with sudo ufw allow 5001. Or test from a Linux machine.
Is my ping to the VPS the latency my visitors or players get? Only for your own connection. Every visitor reaches the server over their own provider and route, so ask users in a few places to run the same 100 pings, or test from servers near them. For Minecraft, our Mumbai guide also reads the game's own ping display.
Why does mtr show 100% loss at the last hop when the site works?
The destination doesn't answer ping. Akamai's guide describes this case: the traffic arrives, but the report "shows loss because the destination host is not sending a reply". Run mtr in TCP mode, mtr -T -P 443, to a port the server listens on.
Can I leave the iperf3 server running?
Better not. Without the authentication options in its manual, anyone who finds the port can run tests that use your traffic, and Debian fixed two security issues in its iperf3 package in August 2025 (CVE-2025-54349 and CVE-2025-54350). For a single test, iperf3 -s -1 handles one client and then exits.
Sources
All opened on 31 October 2026:
- iperf3: manual, Ubuntu 24.04, manual, Debian 12, FAQ, source files iperf_error.c, iperf_udp.c, iperf_locale.c and main.c
- iperf3 packages: Debian 12 debconf template, config script and changelog, Ubuntu 24.04 template and package
- mtr: mtr(8), Debian 12, source report.c and mtr.c, mtr-tiny install script for Debian 12 and Ubuntu 24.04, mtr-tiny on Ubuntu 24.04
- ping(8), Debian 12
- Akamai: Diagnosing Network Issues with MTR
- Ookla: Speedtest CLI, the speedtest.md documentation in the Linux x86_64 download, apt repository
- speedtest-cli: GitHub repository and README, packages for Debian 12 and Ubuntu 24.04
- IETF: RFC 6349, Framework for TCP Throughput Testing
- ESnet fasterdata: iperf2 and iperf3, host tuning background
- iperf2: iperf(1), Debian 12, package on Ubuntu 24.04
- Other tools: curl manual, tar(1), ufw(8), crontab(5), ssh(1)