To validate packet loss, provide a 5–10 minute WinMTR log (Ethernet only), traceroute output to the affected server, continuous ping results during the issue, exact timestamps, and confirmation of WAN stability. Incomplete or WiFi-based logs delay classification.
Why Proper Logs Matter
Packet loss must be:
- Measured over time
- Captured under correct test conditions
- Interpreted using hop propagation logic
Single screenshots or short 10-second tests are not valid evidence. Structured logs allow support to:
- Identify where packet loss begins
- Determine if loss propagates
- Classify LAN vs ISP vs peering vs international
- Decide whether escalation criteria are met
Interpretation reference: How to Interpret Traceroute Results for Packet Loss. Classification reference: How UrbanX Diagnoses Gaming Packet Loss.
Log Collection Workflow
Use Ethernet (Mandatory)
- Connect directly to the router via Ethernet. Disable WiFi on the test device. Ensure no large uploads are running.
- WiFi testing invalidates packet loss evidence.
Run WinMTR (Primary Evidence)
- Run WinMTR to the affected game server IP. Requirements: duration 5–10 minutes minimum, during active issue window, full output visible (all hops), packet loss percentage shown.
- Do not crop intermediate hops. WinMTR must show hop-by-hop latency, packet loss percentage, and sent/received packet counts.
Capture Traceroute Output
- Run traceroute (or tracert on Windows) to the same destination. Traceroute helps identify routing transitions, international jumps, and peering exchange behaviour.
- Traceroute alone does not prove packet loss but supports routing classification.
Run Continuous Ping (For Intermittent Issues)
- If packet loss is intermittent: run continuous ping to a stable target, let it run during gameplay, and capture spike patterns.
- Continuous ping reveals micro-drops, latency spikes, and short disconnect events.
Record Timestamps
- Provide: date, start time of issue, end time (if resolved), and whether issue is ongoing.
- Timestamps allow correlation with monitoring logs, area outage events, and WAN sync history.
What Valid Packet Loss Evidence Looks Like
| Requirement | Why It’s Required |
|---|---|
| 5–10 min duration | Short tests miss patterns |
| Ethernet test | Eliminates WiFi interference |
| Loss propagation visible | Confirms real packet loss |
| Full hop list | Identifies loss origin |
| Timestamp provided | Enables log correlation |
| Same destination across tests | Prevents routing mismatch |
Incomplete logs delay classification.
What Invalidates Packet Loss Logs
The following will cause your logs to be rejected or require re-testing:
- Testing over WiFi
- Running test for less than 2 minutes
- Cropped screenshots
- Testing random IP unrelated to game
- Running test while saturating upload
- Providing only speed test results
Speed tests do not measure packet stability.
South African Context
Most local gaming traffic routes through Johannesburg infrastructure. If logs show:
- Stable route until final hop → Server-side
- Loss after international jump → Transit congestion
- Loss begins early and propagates → Possible ISP or access-layer issue
Because UrbanX operates in a multi-FNO environment:
- Escalation requires confirmed access-layer evidence
- Packet loss alone does not justify FNO dispatch
- WAN sync instability must align with loss pattern
Escalation boundary depends on classification.
How to Present Logs Clearly
When submitting logs:
- Include game title and server region
- State Ethernet confirmation
- Attach full WinMTR screenshot
- Include traceroute text output
- Provide timestamps
- Confirm whether WAN remained connected
Clear presentation shortens ticket lifecycle validation.
Key Term: WinMTR
A diagnostic tool that continuously measures latency and packet loss across every hop between your device and a destination server, allowing propagation-based packet loss analysis.
When Escalation May Be Considered
Escalation may occur if:
- Packet loss begins before ISP core
- Loss propagates through downstream hops
- WAN sync instability aligns with log window
- Access-layer indicators present
Escalation does not occur for:
- Final-hop-only loss
- Server congestion
- International routing instability
- WiFi-based packet loss