Speed test commands

One-liners for measuring network performance from a pod or bare-metal node.

Single-stream curl saturates <1 Gbit/s easily but caps far below real link speed on long-RTT or high-bandwidth paths because of TCP window limits. Always run multi-stream when you actually want to know how fast the link is.

For node-to-node measurement use iperf3 directly — it bypasses the HTTP stack entirely and tells you the underlying TCP/UDP throughput. For RDMA see the networking/perf-tuning doc.

Cloudflare — single-stream download (1 GB)

curl -o /dev/null -G 'https://speed.cloudflare.com/__down' \
  --data-urlencode 'bytes=1000000000' \
  --write-out '\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\nSpeed: %{speed_download} bytes/s\n'

Public, anonymous, IPv6-friendly. Useful baseline against any in-house mirror.

Cloudflare — single-stream upload (200 MB)

curl -X POST https://speed.cloudflare.com/__up \
  -H "Content-Type: application/octet-stream" \
  --data-binary @<(dd if=/dev/zero bs=1M count=200 2>/dev/null) \
  --write-out '\nUpload: %{speed_upload} bytes/s\n' \
  --output /dev/null

Hetzner — multi-stream download (4 × 100 MB)

url='https://ash-speed.hetzner.com/100MB.bin'
n=4
t0=$(perl -MTime::HiRes=time -e 'print time')

b=$({ for ((i=0;i<n;i++)); do
        curl -sS -o /dev/null -w '%{size_download}\n' "$url" &
      done; wait
    } | awk '{s+=$1} END{print s+0}')

awk -v b="$b" -v t0="$t0" -v t1="$(perl -MTime::HiRes=time -e 'print time')" \
  'BEGIN{t=t1-t0; printf "Bytes: %.0f\nTime: %.3fs\nSpeed: %.2f MiB/s / %.2f Gbit/s\n", b,t,b/t/1048576,b*8/t/1e9}'

Single-stream curl maxes out around line-rate / RTT. Use multi-stream to flood links and confirm the host is not the bottleneck.

iperf3 — TCP bidirectional, 8 streams

# server side
iperf3 -s -p 5201

# client side
iperf3 -c <peer> -p 5201 -P 8 -t 30 --bidir

Best for measuring underlay TCP between two hosts with no HTTP middleware in the way.

iperf3 — UDP @ 25 Gbit/s

iperf3 -c <peer> -u -b 25G -t 30 -l 8K

Watch for "lost/total" datagrams in the summary — non-zero loss means PFC misconfig, drops on a port, or wrong MTU.

GitHub — clone throughput

time git clone --depth=1 https://github.com/torvalds/linux /tmp/linux-test && rm -rf /tmp/linux-test

Useful sanity check from inside a pod when you suspect the egress NAT or proxy is the bottleneck.

curl — full timing breakdown

curl -o /dev/null -sS https://example.com/large-file \
  --write-out 'NS:    %{time_namelookup}s
TCP:   %{time_connect}s
TLS:   %{time_appconnect}s
First: %{time_starttransfer}s
Total: %{time_total}s
Bytes: %{size_download}
Speed: %{speed_download} B/s
'

When something feels slow, this tells you whether it is DNS, TCP handshake, TLS, server-side first-byte, or the actual transfer.