Understanding GoSpeed Tests
gospeed runs up to 9 network tests that measure different dimensions of your connection quality. This guide explains what each test measures, when it matters, the key terminology involved, and how the A–F grading system evaluates your results.
Contents
Latency TCP
What It Measures
Latency measures the round-trip time (RTT) — how long it takes for a small message to travel from the client to the server and back. gospeed sends 20 TCP echo probes and records the time for each, then reports the minimum, average, 95th percentile, and maximum values in milliseconds.
Why It Matters
- Interactive applications — video calls, gaming, remote desktops, and SSH sessions feel sluggish when RTT is high
- TCP performance — throughput is bounded by the bandwidth-delay product (BDP); higher latency means TCP needs larger buffers to fill the pipe
- Baseline metric — latency is measured before other tests to establish a reference for bufferbloat comparison
Key Terminology
- RTT (Round-Trip Time) — time for a packet to go from source to destination and back
- P95 — the 95th percentile; 95% of samples were at or below this value, capturing tail latency
- Jitter — variation in latency over time (measured separately in the jitter test)
Grading
The latency grade is based on the worse of average and P95 (95th percentile) latency. This ensures that connections with low average but high tail latency — which cause intermittent lag spikes — are not misleadingly graded as excellent.
| Grade | Threshold (Avg or P95) | What It Means |
|---|---|---|
| A | < 20 ms | Excellent — imperceptible delay for real-time apps |
| B | < 50 ms | Good — comfortable for gaming and video calls |
| C | < 100 ms | Fair — noticeable lag in interactive use, fine for browsing |
| D | < 200 ms | Poor — voice calls start to feel awkward, gaming is impaired |
| F | ≥ 200 ms | Very poor — typical of satellite links or severely congested paths |
These thresholds align with ITU-T G.114, which recommends < 150 ms one-way delay for voice. The grade uses the worse of average and P95 because tail latency matters — a connection averaging 15 ms but spiking to 200 ms at P95 will cause noticeable lag in real-time applications. Google SRE practices similarly emphasize P95/P99 over averages for latency SLOs.
Path MTU UDP
What It Measures
Path MTU discovery determines the Maximum Transmission Unit — the largest packet size (in bytes) that can traverse the entire network path between client and server without being fragmented. gospeed sends UDP packets with the Don't Fragment (DF) bit set at decreasing sizes until one gets through.
Why It Matters
- Fragmentation overhead — packets larger than the path MTU get fragmented, adding CPU overhead and increasing loss probability (if any fragment is lost, the entire packet must be retransmitted)
- VPN and tunnel users — tunnels add encapsulation headers that reduce the effective MTU; a low MTU often indicates misconfigured tunnel overhead
- Throughput efficiency — smaller MTU means more header overhead per byte of payload, reducing effective throughput
Key Terminology
- MTU — Maximum Transmission Unit; the largest IP packet a link can carry without splitting
- DF bit — Don't Fragment flag in the IP header; routers drop oversized packets instead of fragmenting them
- PMTUD — Path MTU Discovery; the process of probing to find the path MTU
- MSS — Maximum Segment Size; MTU minus IP and TCP headers (typically MTU − 40 for IPv4)
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | ≥ 1500 bytes | Standard Ethernet MTU — no overhead or restriction |
| B | ≥ 1400 bytes | Slight reduction, common with VPNs (WireGuard, IPsec) |
| C | ≥ 1200 bytes | Notable reduction, double encapsulation or restrictive network |
| D | ≥ 576 bytes | Minimum MTU guaranteed by IPv4 spec — high fragmentation risk |
| F | < 576 bytes | Below IPv4 minimum — severely broken path |
1500 bytes is the standard Ethernet MTU and the baseline expectation. 576 bytes is the minimum MTU that all IPv4 hosts must support (RFC 791). Anything below that indicates a fundamentally broken network path.
TCP Throughput TCP
What It Measures
This test measures the maximum sustained bandwidth achievable over TCP. gospeed opens multiple parallel TCP streams (default: 4) and pushes data for a configurable duration, using BDP-aware buffer sizing to ensure the pipe is fully saturated. The result is reported in Mbps or Gbps.
Why It Matters
- Bandwidth verification — confirms whether your ISP delivers the speed you're paying for
- Large file transfers — directly determines how fast you can upload/download files, backups, or container images
- Streaming quality — 4K video requires ~25 Mbps; insufficient throughput causes buffering
Key Terminology
- BDP (Bandwidth-Delay Product) — bandwidth × RTT; the amount of data "in flight" needed to fill the pipe
- Mbps / Gbps — megabits / gigabits per second (note: 1 byte = 8 bits)
- Multi-stream — multiple parallel TCP connections to overcome single-flow bottlenecks (e.g., window size limits)
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | ≥ 100 Mbps | Excellent — handles 4K streaming, large downloads, and multi-user households |
| B | ≥ 50 Mbps | Good — comfortable for most workloads including HD streaming |
| C | ≥ 25 Mbps | Adequate — single 4K stream works, multi-user gets tight |
| D | ≥ 10 Mbps | Limited — HD streaming possible, large transfers are slow |
| F | < 10 Mbps | Insufficient — basic browsing only, video calls may struggle |
100 Mbps is the modern baseline for a quality broadband connection. The FCC defines 25 Mbps as the threshold for "broadband," placing it at grade C — functional but below today's expectations.
Bufferbloat TCP + UDP
What It Measures
Bufferbloat measures how much your latency increases under load. gospeed saturates the connection with TCP upload traffic across multiple streams while simultaneously sending latency probes on the control channel. The result is expressed as RPM (Round-trips Per Minute) — how many round-trips the connection can complete in 60 seconds while under full load.
Why It Matters
- Real-world responsiveness — raw speed means nothing if latency spikes to 500 ms whenever someone starts a download
- Gaming + video calls — bufferbloat is the #1 cause of lag spikes during concurrent usage
- Queue management — a low RPM indicates your router or ISP lacks proper queue management (AQM/SQM)
- Network quality — Apple introduced RPM as a key metric because throughput alone doesn't capture user experience
Key Terminology
- RPM (Round-trips Per Minute) — 60000 / loaded_latency_ms; higher is better
- Bufferbloat — excessive buffering in network equipment that causes high latency under load
- AQM / SQM — Active Queue Management / Smart Queue Management; algorithms (like fq_codel, CAKE) that prevent buffer bloat by intelligently dropping or marking packets
- Loaded vs Unloaded latency — latency measured during a throughput test vs at idle; the difference reveals bufferbloat severity
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | ≥ 400 RPM | Excellent — loaded latency ≤ 150 ms; well-managed queues |
| B | ≥ 200 RPM | Good — loaded latency ≤ 300 ms; minor bufferbloat |
| C | ≥ 100 RPM | Fair — loaded latency ≤ 600 ms; noticeable lag under load |
| D | ≥ 50 RPM | Poor — loaded latency ≤ 1.2 s; gaming and calls break down |
| F | < 50 RPM | Severe — loaded latency > 1.2 s; connection feels unusable under load |
Apple's responsiveness metric considers ≥ 400 RPM as "high" quality. At < 50 RPM, each round-trip takes over a second under load — the connection is effectively unusable for interactive tasks while any large transfer is in progress.
UDP Throughput & Packet Loss UDP
What It Measures
UDP throughput measures the maximum bandwidth achievable over UDP, along with packet loss and packet reordering statistics. Unlike TCP, UDP has no congestion control or retransmission, so this test reveals the raw capacity and stability of the network path. gospeed caps the UDP send rate based on TCP throughput results to avoid overwhelming the link.
Why It Matters
- Real-time protocols — VoIP, video conferencing, and game networking use UDP because retransmission would add unacceptable delay
- Media streaming — protocols like RTP/RTSP run over UDP; loss and reordering directly affect audio/video quality
- Network path analysis — comparing TCP vs UDP throughput reveals whether congestion control or path issues are the bottleneck
Key Terminology
- Packet loss — percentage of sent packets that never arrive
- Packet reordering — packets arriving in a different order than sent; causes jitter in real-time streams
- Rate cap — gospeed limits UDP send rate to avoid causing unnecessary congestion; capped at the ceiling of TCP throughput
- Loss rate — (packets lost / packets sent) × 100, expressed as a percentage
- Congestion loss — packets dropped by routers when buffers overflow
- Random loss — packets lost due to physical layer errors (wireless interference, bad cables)
Grading
The UDP test grade is based on the worse of packet loss and throughput. Both metrics must be good for the test to receive a high grade — matching the ITU-T Y.1541 and Y.1564 "all must pass" philosophy where every KPI must meet its threshold independently.
| Grade | Packet Loss | Throughput | What It Means |
|---|---|---|---|
| A | < 0.1% | ≥ 100 Mbps | Excellent — near-zero loss with ample bandwidth for any real-time application |
| B | < 0.5% | ≥ 50 Mbps | Good — imperceptible loss, multiple simultaneous streams supported |
| C | < 1.0% | ≥ 25 Mbps | Fair — occasional audio glitches or limited bandwidth for HD streams |
| D | < 2.5% | ≥ 10 Mbps | Poor — voice calls degrade, single-stream real-time use only |
| F | ≥ 2.5% | < 10 Mbps | Severe — real-time communication is unreliable |
The grade uses the worse of both metrics because a connection with zero loss but negligible throughput (or vice versa) is not truly healthy. This approach follows ITU-T Y.1541 which requires all performance parameters to meet their class thresholds independently, and RFC 2544 which evaluates throughput and frame loss as separate pass/fail criteria.
Jitter UDP
What It Measures
Jitter measures the inter-packet delay variation — how consistently packets arrive compared to their expected timing. gospeed calculates jitter using the RFC 3550 algorithm: a running average of the absolute difference between expected and actual inter-arrival times.
Why It Matters
- Voice and video quality — codecs expect packets at regular intervals; jitter forces the receiver to use a jitter buffer, adding latency
- Gaming — variable packet timing causes "rubber-banding" and desynchronization in multiplayer games
- Network stability — high jitter often indicates congestion, route flapping, or wireless interference
Key Terminology
- Inter-packet delay variation — the difference in one-way delay between consecutive packets
- RFC 3550 — RTP standard that defines the jitter calculation as an exponentially weighted moving average
- Jitter buffer — a buffer at the receiver that absorbs timing variations; larger buffer = more latency
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | < 5 ms | Excellent — minimal buffering needed, crystal-clear VoIP |
| B | < 10 ms | Good — small jitter buffer handles it, no perceptible impact |
| C | < 20 ms | Fair — jitter buffer adds noticeable delay, occasional artifacts |
| D | < 50 ms | Poor — large jitter buffer required, real-time apps struggle |
| F | ≥ 50 ms | Severe — real-time audio/video is unreliable |
Cisco recommends < 30 ms jitter for VoIP. The grade A threshold of 5 ms ensures that even without a jitter buffer, packet timing variations are imperceptible. At 50 ms+, even aggressive jitter buffers cannot fully compensate.
DNS Resolution UDP/53
What It Measures
This test measures how quickly your configured DNS resolver responds to queries. gospeed resolves the server's hostname multiple times and records the response time in milliseconds. Fast DNS is critical because every new connection starts with a DNS lookup.
Why It Matters
- Page load speed — a typical webpage triggers 20–100 DNS lookups; slow DNS adds hundreds of milliseconds
- First-connection latency — the very first request to any domain is bottlenecked by DNS
- Resolver choice — your ISP's DNS may be slower than public resolvers (1.1.1.1, 8.8.8.8); this test quantifies the difference
Key Terminology
- DNS (Domain Name System) — translates hostnames (e.g., example.com) to IP addresses
- Resolver — the DNS server your system is configured to use (often your router or ISP)
- TTL (Time To Live) — how long a DNS response is cached; subsequent lookups within the TTL are instant
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | < 10 ms | Excellent — local or nearby resolver, near-instant lookups |
| B | < 30 ms | Good — fast public resolver or well-configured ISP DNS |
| C | < 75 ms | Fair — adds noticeable delay to first connections |
| D | < 200 ms | Slow — consider switching to a faster DNS resolver |
| F | ≥ 200 ms | Very slow — every new connection is delayed by hundreds of milliseconds |
Modern DNS resolvers (Cloudflare, Google) typically respond in under 10 ms from nearby PoPs. At 200 ms+, DNS alone adds a noticeable pause every time you visit a new website or connect to a new service.
TCP Connect TCP
What It Measures
TCP Connect measures the time it takes to establish a TCP connection — the three-way handshake (SYN → SYN-ACK → ACK). This is the minimum overhead before any data can flow and is measured independently from application-level latency.
Why It Matters
- Connection-heavy workloads — HTTP/1.1 without keep-alive, microservices, and API calls each open new connections
- TLS overhead — TLS adds 1–2 additional round-trips on top of the TCP handshake; slow connect time compounds with TLS
- Firewall/middlebox detection — unusually slow connect times can indicate SYN inspection, rate limiting, or geographic routing issues
Key Terminology
- Three-way handshake — SYN, SYN-ACK, ACK; the TCP connection establishment sequence
- SYN — the first packet sent by the client to initiate a connection
- TTFB (Time To First Byte) — includes DNS + TCP connect + TLS + server processing; connect time is one component
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | < 50 ms | Excellent — fast handshake, minimal connection overhead |
| B | < 100 ms | Good — acceptable for most applications |
| C | < 200 ms | Fair — connection setup is noticeable, especially with TLS |
| D | < 500 ms | Slow — each new connection adds significant delay |
| F | ≥ 500 ms | Very slow — connections time out frequently, possible middlebox interference |
TCP connect time is roughly 1x RTT in the best case (SYN + SYN-ACK). The thresholds are wider than latency because connect time can include server-side SYN queue processing. At 500 ms+, many applications will hit their connection timeout defaults.
Bidirectional Throughput TCP
What It Measures
The bidirectional test measures simultaneous upload and download throughput. Unlike the standard TCP test which measures one direction at a time, this test runs both directions concurrently using multiple parallel streams in each direction. The results show upload and download speeds achieved under full-duplex load.
Why It Matters
- Real-world simulation — most connections carry traffic in both directions at once (video calls, file sync, web browsing with uploads)
- Full-duplex verification — some links (especially asymmetric DSL or cable) suffer significant throughput drops when both directions are active simultaneously
- QoS and fairness — reveals whether your router or ISP prioritizes one direction over the other under contention
- Video conferencing — requires sustained bandwidth in both directions; single-direction tests miss contention issues
Key Terminology
- Full-duplex — simultaneous two-way communication; both upload and download happen at the same time
- Half-duplex — only one direction at a time; some wireless links (especially older Wi-Fi) operate this way
- Asymmetric link — a connection where upload and download speeds differ (common with cable and DSL)
- Contention — competing traffic in both directions sharing the same bottleneck link
Grading
| Grade | Threshold | What It Means |
|---|---|---|
| A | ≥ 100 Mbps | Excellent — strong throughput maintained in both directions simultaneously |
| B | ≥ 50 Mbps | Good — comfortable for concurrent uploads and downloads |
| C | ≥ 25 Mbps | Adequate — some contention visible but workable |
| D | ≥ 10 Mbps | Limited — full-duplex workloads are constrained |
| F | < 10 Mbps | Insufficient — significant degradation under bidirectional load |
Graded on the same throughput scale as TCP. The grade is based on the slower direction (whichever of upload or download has lower throughput), ensuring the grade reflects the weakest link under full-duplex load. Comparing bidirectional results to single-direction TCP results reveals how much throughput is lost to contention — a large drop indicates the link or router cannot handle full-duplex traffic efficiently.