---
title: Packet loss, MTR and Pingplotter
description: "### 🔊 Troubleshooting with MTR, Pingplotter and Ping This guide is useful for identifying where extra latency or packet loss occurs. Gamers should take a look at our Advice for Gamers guide - it's a collection of tips and advice for troubleshooting…"
url: "https://www.atomic.co.za/docs/mtr-pingplotter/"
updated: "2026-06-14"
category: Advanced Guides
tags:
  - MTR
  - Packet Loss
  - Pingplotter
---

# Packet loss, MTR and Pingplotter

### 🔊 Troubleshooting with MTR, Pingplotter and Ping

This guide is useful for identifying where extra latency or packet loss occurs.

Gamers should take a look at our Advice for Gamers guide - it's a collection of tips and advice for troubleshooting international game latency issues. Often, the solution is to set up more direct peering with game hosting companies at the optimal internet exchange, which can take a few days. You can also open a support ticket with the game and ask them to share their IP addresses or request troubleshooting advice.

### 🎮 Finding a Game Server IP

Close your other applications, then run the game and check for open UDP / TCP connections:

**Windows TCP:** Use **Resource Monitor** and look for items with the highest **TCP** traffic rates, or run the command: **netstat -n | findstr ESTABLISHED** in Command Prompt or PowerShell.

**Windows UDP:** Use **Resource Monitor** and look for items with the highest **UDP** traffic rates, or download [TCPView](https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview) and look for UDP traffic items.

**macOS:** lsof -Pnl +c0 +M -i4

**Linux:** netstat -taunp

**Other / PlayStation:** Sometimes people share the IPs of the game servers on forums. You can also use Wireshark / tcpdump if you can inspect the traffic on your router or a device between your PlayStation and the internet.

### ⛳️ How to run an MTR / Pingplotter test from your device

My Traceroute (MTR) is a tool that combines the functionality of traceroute and ping. It's useful for testing end-to-end network connectivity and locating extra latency or packet loss along the way. How to run an MTR test:

Connect a laptop directly to your fibre box (ONT / CPE) or router with an Ethernet cable. [Openserve](https://www.atomic.co.za/docs/configure-a-pppoe-login-on-a-laptop/) has an extra step.

Windows and macOS users can use [PingPlotter](https://www.pingplotter.com/) - configure it to do at least 180 tests (1/sec). Windows users can also install [WinMTR](https://winmtr.net/).

If you are familiar with the macOS/Linux terminal, run the command:

```
mtr 8.8.8.8
```

If you know the IP address of the server you want to monitor, like a game server, use that IP (replace 8.8.8.8).

You can also run mtr in report mode. The following command will give you a 60-second report:

```
mtr -c 60 --aslookup --show-ips -w 8.8.8.8
```

If you find a problem, please email us the following:

1. Screenshot of your test result (showing the command you used)
2. Details of which fibre network you are on, and your general location

### 🏎️ How to run an MTR test from the Atomic datacentre

Visit the [Atomic looking glass](https://atomic.co.za/maintenance-in-progress?old=https%3A%2F%2Flg.atomic.ac%2F). Select a view, or select multiple views. Select MTR, then enter the IP address you would like to run the MTR test on.

Views:

- ipt1: isolated to IP transit provider 1 for incoming and outgoing traffic
- ipt2: isolated to IP transit provider 2 for incoming and outgoing traffic
- view1: blend of ipt1 and ipt2 based on the best path - standard routing for most customers

### 🧩 How to read MTR or Pingplotter output

When reading MTR output, you have to keep **Control Plane Policing** (CoPP) in mind. Tools like traceroute and mtr require a router to send packets to its CPU for processing. CPU is a limited resource, and often routers have rate limits configured for this kind of traffic. If you see a router **in the middle** of the output list with packet loss or extra latency, it could be because of CoPP. If later in the output there is no loss - it's best to **trust the later hops**. If the **last hop** is **not** showing loss, you can be fairly sure there is no packet loss, and the hops in the middle showing loss are doing so because of CoPP.

If there is packet loss at the first hop, it could be caused by your WiFi router, fibre box or the fibre network (last mile or backhaul).

### 🕹️ How to run a Ping test to detect packet loss on your line

Connect a laptop directly to your fibre box (ONT / CPE) or router with an Ethernet cable.

Open the terminal and use ping or fping. Start with a **small** packet ping:

```
ping 102.135.242.1
```

Optionally, also do a big packet ping test with the "Don't Fragment" bit enabled (1500-byte packets) to detect MTU problems:

Windows: `ping -f -l 1472 102.135.242.1`

macOS: `ping -D -s 1472 102.135.242.1`

Linux: `ping -M do -s 1472 102.135.242.1`

MTU - **28 bytes** for IPv4, MTU - **48 bytes** for IPv6, so 9k MTU ping with IPv6 = 8952

If you are using PPPoE, reduce the packet size by 8 bytes

If you see packet loss, please email us the following:

1. Screenshot or text output of your test
2. Details of which fibre network you are on, and your general location

### 🎯 More troubleshooting

If these tests don't show a problem, we suggest you do an 80% UDP test using [iPerf](https://www.atomic.co.za/docs/iperf) next, or have a look at our [troubleshooting overview](https://www.atomic.co.za/docs/overview-of-fibre-troubleshooting/) guide.