Measuring Latency and Packet Loss

Test from our side: the Looking Glass

Our Looking Glass runs tests from our locations in Lisbon, Johannesburg and Lagos to any address you give it. Choose a test location (select more than one to compare them), enter a public IP address or hostname, and choose a test:

• Ping (IPv4 or IPv6): round-trip time and loss to the address.
• Traceroute (IPv4 or IPv6): the route the traffic takes.
• MTR (IPv4 or IPv6): the route and the loss and latency at every step, the most useful of the three.
• DNS lookup, HTTP timing and TLS certificate for testing a website.

Before you order, test from each location to your own address or to your users' networks and choose the location that answers best. After you order, test from your server's location to your address to see the path back to you.

Test from your side: mtr

mtr combines ping and traceroute and is what we will ask for. Run it from your computer to your server's address, with 100 probes:

Linux (install the mtr or mtr-tiny package):

mtr -rwbzc 100 203.0.113.10

macOS (install with Homebrew, brew install mtr):

sudo mtr -rwbzc 100 203.0.113.10

Windows has pathping built in. It sends 100 probes to every hop, so it takes several minutes:

pathping 203.0.113.10

Add -6 to mtr to test over IPv6. The options mean: report mode, wide output, show addresses as well as names, show network (AS) numbers, 100 probes.

Reading the results

• Loss in the middle that does not continue is not loss. Routers answer test probes at low priority and often ignore some of them. Loss that shows at one hop but not at the hops after it, or not at the last hop, does not affect your traffic. Real loss starts at one hop and continues to the last.
• Latency is the same. A jump at one hop that falls back at the next is that router answering slowly. A rise that stays for every hop after it shows where the delay is added.
• Distance sets a floor. Latency grows with the distance the cable travels, which is often longer than the straight line.
• Test when the problem happens, with enough probes. A ten-packet test can miss loss that comes and goes; use at least 100, at the time of day the problem appears.

Before you blame the network

• Your server's firewalls. Rules in the server's Firewall Rules card, the Edge Firewall card, or the firewall inside the operating system can drop ICMP, the protocol ping and mtr use. Ping then fails although the server is reachable. See Firewall.
• Throttled traffic. If the Bandwidth Usage card shows Throttled, the server has used its included traffic for the period and runs at reduced speed until the next one. See Monitoring Your Server and Usage.
• A busy server. High CPU or memory use makes a server slow to answer. Check the Metrics graphs on the server page.
• Your own connection. Wi-Fi and a busy local network add loss and latency. Repeat the test from another network or over a cable.

What to send us

If the loss, or a rise in latency that does not fall back, starts inside our network, open a support ticket with:

• the server name and its IP address;
• your public IP address;
• your mtr (or pathping) report from your computer to the server;
• the Looking Glass MTR from your server's location to your public IP address;
• the time of the tests in UTC, and whether the problem is constant or comes and goes.

If the loss starts inside your own provider's network, contact your provider and send them the same reports.

What our support covers

Your server is self-managed. You have full root access and complete control over what runs on it. Our support covers our network, our hardware and the platform itself. As a matter of policy we do not log in to customer servers, so software and configuration inside the server stay under your control.