# What Logs to Provide for Packet Loss Issues

Source: https://urbanx.co.za/knowledge-hub/support-diagnostics/logs-for-packet-loss-issues

**Answer:** 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.

Part of [Gamer-Centric Support & Intelligent Diagnostics](https://urbanx.co.za/knowledge-hub/support-diagnostics) · 10 min read · by UrbanX Support Engineering

## 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](/knowledge-hub/gaming-performance/interpret-traceroute-packet-loss). Classification reference: [How UrbanX Diagnoses Gaming Packet Loss](/knowledge-hub/support-diagnostics/urbanx-diagnoses-gaming-packet-loss).

## Log Collection Workflow

1. **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.
2. **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.
3. **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.
4. **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.
5. **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 |

> **WARNING:** 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

> **INFO:** 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

> **TIP:** Clear presentation shortens ticket lifecycle validation.

## Key Term: WinMTR

- **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

## Frequently Asked Questions

**Is 1% packet loss enough to report?**

Yes, if sustained and confirmed via proper testing.

**Why must the test run for 5–10 minutes?**

Short bursts miss intermittent instability patterns.

**Does traceroute prove packet loss?**

No. It supports routing analysis but WinMTR is primary evidence.

**Can I test to Google instead of the game server?**

No. Testing must match the affected destination.

**Why was my packet loss report rejected?**

Likely due to insufficient duration, WiFi testing, or lack of propagation evidence.