Measure it yourself
Every latency figure on this site comes from our own probes, which is exactly the sort of claim you should not take on trust. The looking glass runs from all 34 sites, needs no account, and answers the only question that matters: what does the path between you and that city actually look like right now.
Build the command
Pick a site and a tool. These run from your machine, against our published test hosts, which is the only measurement that tells you anything about your own path.
mtr -rwzbc 100 lg-ams-01.paragonvps.comA 1 GB file of incompressible random data, for measuring throughput rather than your compressor.
Run each of these three times at different hours before drawing a conclusion. A single traceroute during someone else’s maintenance window is not evidence.
What it is, and what it is not
A probe host at every site, on the same VLAN as production, behind the same filtering.
The looking glass is a small host in each site that runs tests on your behalf and prints the raw output. It sits on the same network as customer instances and behind the same edge filtering, so what it measures is what you would get. No optimised test path, no separate uplink, no quiet corner of the rack.
It is not a benchmark and it is not a marketing tool. Some of the results are unflattering: Sydney to anywhere is expensive in milliseconds, and Johannesburg is still settling its transit. Those numbers are there because hiding them would be pointless when anyone can run the test.
All 34 sites, all the time
Including pre-order sites. Johannesburg has been answering probes since before it had a single paying instance on it.
No account, no sign-up
Consistent with the rest of the service. The only test requiring anything from you is iperf3, and that needs a token purely to stop the box being used as a flood source.
Rate-limited, deliberately
One test at a time per source address and four tests a minute. A looking glass is a lovely amplification vector if the operator has not thought about it.
Results are yours
Output is plain text with a permalink that lives for thirty days. Paste it into a ticket, or into an argument with someone else’s network team.
What you can run
Five tests, chosen because they answer different questions. Running all of them proves little; picking the right one usually settles the matter in a minute.
Start with MTR, not ping
One ping tells you about one moment. Three hundred MTR cycles tell you whether the path is bad, occasionally bad, or fine and you were unlucky.
Use the test file first for throughput
A 1 GB download over HTTPS reproduces what most real workloads do. If that is slow but iperf3 is fast, the problem is congestion control or middleboxes rather than capacity.
Path MTU is worth ninety seconds
A surprising share of “the site loads but large uploads hang” tickets end here, usually at a tunnel someone forgot about between you and us.
| Test | The question it answers | Limits |
|---|---|---|
| ICMP ping | Is it reachable, and what is the round trip right now | Up to 100 packets per run |
| Traceroute (ICMP and UDP) | Which hops the forward path takes leaving that site | 30 hops maximum, 3 probes per hop |
| MTR | Loss and latency per hop over time instead of in one snapshot | Up to 500 cycles, roughly 8 minutes |
| iperf3 target | What throughput you can really get to that site | Panel token, 60 seconds, up to 4 streams |
| Test file | A throughput answer without installing anything | 100 MB and 1 GB over HTTPS |
| Path MTU probe | Whether something in the middle is eating large packets | Reports the largest size that survives |
Reading the output without misreading it
Traceroute output is not a picture of your traffic. It is a set of replies from routers that had better things to do, and reading it as a latency graph produces confident, wrong conclusions.
Most routing complaints we receive are correct about the symptom and wrong about the hop.
Middle hops exaggerate
A router replying to a traceroute probe is doing it on its control plane, which is busy and treats ICMP as the lowest priority thing it owns. When one hop shows 180 ms and the next shows 14 ms, that first router was occupied, not the path in front of it.
Only the last line is real
Loss that appears at hop six and vanishes at hop seven is rate-limited replies, not lost traffic. When it starts at hop six and continues all the way to the destination, send us the output.
Reverse DNS is a hint
Airport codes in hop names are frequently stale by years. Treat them as an indication of intent by whoever named the interface, never as evidence of geography.
MPLS hides the middle
Paths crossing a label-switched core can look three hops shorter than they are. The latency is still there; only the honesty about where it came from is missing.
Physics sets the floor
Amsterdam to Singapore is roughly 168 ms and no amount of peering will improve on it meaningfully. If your measurement is close to our published figure, the path is working correctly and the answer is a second site rather than a ticket.
Asymmetric routes, where the confusion lives
A traceroute measures the forward path and nothing else. Every number in it, though, includes the return trip of that hop’s reply, and the return trip may take an entirely different route across the planet.
Traffic from us to you and traffic from you to us are separate decisions made by separate networks. We choose what leaves; the networks in between choose what comes back. Most operators hand traffic off at the earliest opportunity, so your return path frequently leaves your provider in a different city from the one where our path entered it.
The visible consequence is a hop that looks slow while your actual traffic is fine. Worse is the invisible one: congestion on the return path surfaces as latency you will spend an afternoon hunting for in the forward direction.
Always measure both directions
MTR from your machine to the instance, and MTR from the looking glass at that site back to your address, ideally running at the same time. Half the evidence produces half an answer.
Asymmetry on its own is not a fault
Nearly every path on the internet is asymmetric and nearly all of them work. It becomes a problem only when one direction is congested, drops packets, or crosses a filtering box that keeps state.
We can only influence what returns
Our routing policy controls the outbound direction directly. The return path changes only if we announce differently, hand off somewhere else, or ask a peer nicely. All three are possible; none is instant.
Stateful middleboxes hate asymmetry
If you run a firewall that expects to see both directions of a flow and the return path stops crossing it, you get intermittent resets that look exactly like a network fault. Check this before blaming anyone.
Filing a routing complaint that gets acted on
Median first response on a ticket is 11 minutes. A routing fix takes longer, because someone else has to agree.
- 01
Rule out your own instance
Check load, connection tracking, the instance’s own interface counters and whether a filtering rule of yours is dropping traffic. Something like one report in five ends here, and it ends faster if you look first.
- 02
Collect both directions
At least 300 MTR cycles from your side and 300 from the looking glass at that site, run in the same window. Attach the permalink rather than a screenshot; we need the numbers, not a picture of them.
- 03
Timestamp it properly
UTC or an explicit offset. “This morning” describes a moment for you and a range of eleven hours for us, and correlating flow data against it is guesswork.
- 04
Say what changed and when
Always been like this, or started on Tuesday. Continuous, or between 20:00 and 23:00 local. That single sentence usually decides whether we are looking at a peering change or at somebody’s evening congestion.
- 05
Send it to support
Mail [email protected] or open a ticket in the panel. Anything that turns out to be a real path problem gets escalated to the network team the same hour, and you get told what we asked the other network for.
What we can do: repath, depreference a transit, ask a peer to investigate, or move you to a site with a better route. Congestion inside a network we do not touch is beyond all four, and there we route you around the problem rather than spending a week being right.
Looking-glass questions
For sixty seconds at a time, yes. The token exists to keep the host from becoming somebody’s flood source, not to ration honest measurement. Sustained testing wants your own instance on both ends.
It should not, and if it does we would like to know. The probe host sits on the same VLAN and inherits the same policy. A genuine difference usually means a per-prefix policy applied to your address, which is worth a ticket.
Not on the public looking glass. Ask in a ticket with a specific prefix and a reason and you will get the answer, including which upstream we are preferring for it and why.
Within the rate limits, yes; the tests are outbound and harmless at that volume. Using it as a measurement source for a target you do not control is fine. As a component of anything larger, it is not.
Thirty days, then they expire along with the stored output. Attach it to a ticket while it still resolves, or paste the text, which we prefer anyway.
Run the test, then pick the city
Latency you measured beats latency somebody published. Once the numbers make sense, the location index has the stock, the uplink and the filtering capacity for each site.