Jump to content

Network Troubleshooting with MTR

From Pulsed Media Wiki


MTR (My Traceroute) combines traceroute and ping into a single tool. It shows every hop between your computer and your Pulsed Media seedbox, along with packet loss and latency at each point. When your connection is slow or dropping, MTR tells you where the problem is.

Network routes change constantly. A path that works fine at noon can develop packet loss at midnight because a transit provider gets congested. Running MTR from both directions (home to server and server to home) catches problems that only show up on one side.

Running MTR

Always let MTR send at least 1000 packets before reading results. Short tests miss intermittent issues. You may need to run the test several times at different times of day.

From your seedbox to home

If you have SSH access to your seedbox:

mtr your.home.ip.address

Replace your.home.ip.address with your actual IP (find it at whatismyipaddress.com).

From home to your seedbox

Windows

Download WinMTR. Run it and enter your seedbox hostname (e.g. servername.pulsedmedia.com). Click Start.

Linux

Install MTR:

# Debian/Ubuntu
sudo apt install mtr

# Red Hat/Fedora
sudo yum install mtr

Run it:

mtr servername.pulsedmedia.com

macOS

Install via Homebrew:

brew install mtr

Run it:

sudo mtr servername.pulsedmedia.com

Reading MTR output

MTR shows one line per network hop. The columns that matter:

  • Loss% — Packet loss at this hop. Loss at the final hop means a real problem. Loss at intermediate hops that does not carry through to later hops is usually ICMP rate-limiting (not a problem).
  • Avg — Average latency in milliseconds. Look for sudden jumps between hops.
  • StDev — Standard deviation. High values mean the latency at that hop is unstable.

A healthy connection shows 0% loss at every hop and latency that increases gradually from hop to hop.

Common problems

High latency at a specific hop that carries to all later hops — congestion or routing issue at that hop. Usually a transit provider, not something you or PM can fix directly. Contact your ISP with the MTR output.

Packet loss at the final hop only — the server or its local network is overloaded. Contact Pulsed Media support.

Packet loss at intermediate hops but 0% at the final hop — ICMP rate limiting. Not a real problem. The packets are getting through fine; the intermediate routers just deprioritize ICMP responses.

Testing loss at three packet sizes

Comparing packet loss at three packet sizes narrows a bad connection down to who can fix it: you, your ISP or Pulsed Media. One pass takes about 17 minutes. MTR probes are 64 bytes by default, while file transfers fill packets up to about 1500 bytes, so a default test can understate the loss your transfers see.

Stop downloads and other heavy traffic first. Then run these three commands at the same time, each in its own terminal, so all three see the same conditions. On macOS, put sudo in front. The -r option prints the results when the 1000 packets finish.

mtr -r -c 1000 -s 64 servername.pulsedmedia.com
mtr -r -c 1000 -s 700 servername.pulsedmedia.com
mtr -r -c 1000 -s 1400 servername.pulsedmedia.com

On Windows, use ping in three Command Prompt windows:

ping -4 -n 1000 -w 1000 -f -l 64 servername.pulsedmedia.com
ping -4 -n 1000 -w 1000 -f -l 700 servername.pulsedmedia.com
ping -4 -n 1000 -w 1000 -f -l 1400 servername.pulsedmedia.com

Compare Loss% on the final hop, or the loss figure in the ping summary. The largest size is 1400 because it also fits links with lower limits, such as the 1492 bytes of PPPoE. If ping reports a fragmentation or message size error, that is a size limit and not loss: lower the size by 100 and run it again.

Loss pattern What it usually means Who can fix it
About the same at all three sizes Congestion or rate limiting, not damaged packets Whoever runs the hop where the loss starts (see Common problems)
Clean up to one size, then almost total A size limit on the path, such as a VPN tunnel or a filter on large ICMP packets Your VPN or router settings, otherwise your ISP
Rises with each size Damaged packets on a cable, port, Wi-Fi link or line. A longer packet has more bits to damage. Find out with the comparison below

To find where a rising pattern starts, repeat the test against your home router's address and against 8.8.8.8:

  • Loss to the router as well: your Wi-Fi, cable or router.
  • Clean to the router, loss to 8.8.8.8 as well: your ISP.
  • Clean to both, loss only to your seedbox: the route or the Pulsed Media network. Send all the results to Pulsed Media support.

A rising pattern is strong evidence, not proof. A full queue also drops large packets more often than small ones, so a pattern that fades on an idle connection or at another time of day points to congestion. Small gaps mean nothing: 1000 packets cannot separate 1% loss from 1.5%.

Local factors that affect your connection

Before blaming the network path, check:

  • Wi-Fi — Distance from router, walls, interference from other devices. Try a wired connection.
  • ISP issues — Run MTR to a known-good server (like 8.8.8.8) to see if the problem is your ISP or the specific route to PM.
  • VPN — VPNs add latency and can introduce packet loss. Try without VPN.
  • Router — Reboot your home router if multiple devices have issues.
  • Antivirus/firewall — Some software inspects network traffic and adds latency.

At Pulsed Media

Pulsed Media runs its own network as AS203003, with its own IP space and core router, from two datacenters in Finland. A fault inside that network is Pulsed Media's to find and fix, with no hosting provider in between.

A failing switch port on that network showed what the rising pattern looks like: loss of about 10% at 64 bytes, 26% at 200 bytes, 53% at 1000 bytes and 73% at 1472 bytes, while a neighbouring machine on the same segment lost nothing. A cable reseat held for about 15 hours before the link failed again. Moving the same cable to another switch gave 0% loss in all 10 samples over 19 minutes. After any cable or port change, repeat the test hours later, because one clean result does not prove the fault is gone.

Packet loss by packet size on one failing switch port. Clean links show no such rise.

Pulsed Media seedboxes run on this network. See available plans.

See also