Speed Test Benchmark

Network tests are easiest to misuse: public endpoints, routing changes, and time-of-day can dominate results. This page documents two quick tools (network-speed.xyz and speedtest-cli) and how to interpret results without over-claiming.

Quick Summary

• Use these tools for a quick throughput snapshot ("is the network obviously broken?").
• Do not treat results as SLA evidence.
• For controlled testing, use iperf3 between two hosts you control; use mtr for path/packet loss investigation.

warning

Avoid piping untrusted remote scripts into bash. Download first, inspect, then run.

Option A: network-speed.xyz

network-speed.xyz is a lightweight script that focuses on download throughput across multiple regions.

Safer way to run

run-network-speed-xyz-safely.sh

mkdir -p ~/nettest
cd ~/nettest

wget -O network-speed.xyz https://network-speed.xyz
sed -n '1,200p' network-speed.xyz

bash network-speed.xyz | tee network-speed.$(date +%F_%H%M%S).log

Decision-oriented summary

Use case	Verdict	Why
Quick network sanity check	Best fit	Fast and focused on throughput
Comparing VPS bandwidth	Best fit	Multiple regions/endpoints
Disk or CPU evaluation	Not suitable	Not a system benchmark
Network SLA validation	Acceptable	Public endpoints only
Production performance validation	Not suitable	No controlled iperf3 methodology
Client/audit reports	Acceptable	Supporting signal only

Strengths

• Focused purely on throughput
• Tests multiple locations
• Fast execution

Limitations

• Public mirrors with variable routing
• Typically no latency/jitter focus
• Not inherently repeatable
• Output not machine-friendly

Option B: speedtest-cli

speedtest-cli runs a speed test against public servers. It can be useful as an extra signal, especially for upload throughput.

Install and run:

install-and-run-speedtest-cli-apt.sh

sudo apt update
sudo apt install -y speedtest-cli

speedtest-cli

Example output:

Interpreting results safely

• Run tests at least 3 times and compare medians.
• Record timestamp, VPS region, provider, and the target server/mirror.
• If results vary wildly, investigate routing/packet loss with mtr.

Audit-grade alternatives

• Throughput: iperf3 (server + client you control)
• Path/loss: mtr, ping, traceroute
• Application-level: real HTTP download/upload to your own storage/CDN endpoint

Controlled throughput test with iperf3

If you need repeatable numbers, run iperf3 between two hosts you control (example: your VPS to a second VPS in another region).

On the server (receiver):

iperf3-server.sh

sudo apt update
sudo apt install -y iperf3

iperf3 -s

On the client (sender):

iperf3-client-download.sh

sudo apt update
sudo apt install -y iperf3

iperf3 -c <SERVER_IP> -P 4 -t 20

Test the reverse direction (upload relative to the client):

iperf3-client-upload-reverse.sh

iperf3 -c <SERVER_IP> -P 4 -t 20 -R

warning

iperf3 -s opens a listening port. If this is on a public server, restrict the firewall to your source IP or run it briefly and stop it after testing.

Investigate routing and packet loss with mtr

When throughput is inconsistent, measure the path.

mtr-basic-report.sh

sudo apt update
sudo apt install -y mtr-tiny

mtr -rwzbc 100 <TARGET_HOST>

Interpretation tips:

• Loss on intermediate hops can be misleading (some routers rate-limit ICMP).
• Focus on loss and latency at the final hop and overall trend.

Result capture template

Keep a small record so you can compare later:

network-test-record-template.txt

date:
vps_host:
provider:
region:
tool:
target:
download_mbps:
upload_mbps:
notes:

Common pitfalls

• Testing during provider maintenance or peak hours
• Comparing two VPS providers from different regions (routing dominates)
• Assuming CDN download speed equals your site's real user experience
• Forgetting to record the selected speedtest server/mirror