To test gaming latency properly, measure ping, jitter, and packet loss using ping, traceroute, or WinMTR over several minutes. Test both idle and under upload load, and identify where latency begins — at your LAN, ISP routing, peering exchange, or international transit.
Why Speed Tests Are Not Enough
A speed test measures throughput (Mbps). Gaming performance depends on latency (ping), jitter, packet loss, and routing stability. You can have 200Mbps download speed and still experience unstable gaming if latency spikes or packets drop. Most South African gaming traffic routes through Johannesburg-hosted infrastructure. CPT players will naturally see slightly higher base latency due to distance, but instability is not normal. Testing must isolate the layer causing delay.
What You Need to Measure
- Base ping (ms)
- Stability over time
- Packet loss percentage
- Where latency increases in the route
- Do not rely on a single ping result — run tests for at least 5 minutes
Step-by-Step Testing Process
Step 1: Establish an Idle Baseline
- Connect via Ethernet.
- Close background applications.
- Ensure no uploads or downloads are running.
- Run: ping -n 50 <reliable South African host> or use WinMTR for 5 minutes.
- Record: average latency, maximum latency, packet loss.
- This is your clean baseline.
Step 2: Test Under Upload Load
- Start a controlled upload: cloud sync, file upload, or streaming upload.
- Run the same ping or WinMTR test.
- If latency increases significantly under load, bufferbloat is present.
- See: What Is Bufferbloat and How to Fix It
Step 3: Run Traceroute or WinMTR
- Traceroute shows each hop between you and the destination.
- Look for: latency spike at hop 1 (LAN/router issue), gradual increase toward Johannesburg (normal geographic routing), sudden jump after leaving South Africa (international routing), or packet loss before peering (routing issue).
- Peering exchanges such as NAPAfrica typically appear in mid-route hops if routing remains local.
- See: What Is NAPAfrica and Why It Matters for Gamers
Step 4: Identify Where Latency Begins
- Use the interpretation table below to match your findings to the correct action.
- Latency that increases consistently with each hop is usually distance-related.
- Latency that spikes suddenly indicates congestion or rerouting.
Step 5: Compare JHB vs CPT Expectations
- JHB to JHB server: lowest base latency.
- CPT to JHB server: slightly higher latency.
- International routing: significantly higher latency.
- If your base ping is stable but higher than expected, it may simply reflect geographic distance.
- If latency fluctuates heavily, investigate congestion or routing instability.
Latency Location Guide
| Where Latency Starts | Likely Cause | Action |
|---|---|---|
| Hop 1 (Router) | LAN issue | Use Ethernet / adjust QoS |
| Early ISP hops | Routing issue | Provide trace to ISP |
| After leaving SA | International routing | Server region issue |
| Final hop only | Server-side | Not ISP controlled |
Definition
A diagnostic tool that displays each routing hop between your device and a destination server. It measures latency at each step, helping identify where delay, jitter, or packet loss begins along the network path.
Common Testing Mistakes
- Testing over WiFi
- Running tests for less than 30 seconds
- Testing only once
- Confusing server-side packet filtering with packet loss
- Assuming higher Mbps equals lower ping
- Latency testing must be time-based, not single-sample
When to Escalate
Escalation is appropriate if you tested on Ethernet, no upload congestion exists, packet loss appears before local peering, and latency spikes occur consistently across sessions. Provide: 5–10 minute WinMTR log, time of testing, and destination tested. Do not escalate based on a single speed test result.
South African Routing Indicators
Efficient local routing: low hop count, stable latency per hop, no sudden international jumps, no early packet loss. International routing indicators: 120ms+ mid-route jump, foreign IP addresses, submarine transit nodes. Understanding routing behaviour prevents incorrect fault attribution.
