Readings
Latency to Cloudflare, Google, Netflix and Meta
One panel per destination, each over a frozen observation window exactly as it comes out of our monitoring. Read every curve on its own terms: the windows differ from one panel to the next.
Graphs taken from our AS210699 Grafana dashboard, shown over a fixed observation window: they illustrate how the network behaves, they do not refresh live.
These curves are frozen. To run a ping, an MTR or a traceroute from our PoP at the moment you are reading this page: Open the Looking Glass on lg.infrawire.net
Reading
How to read these curves
Three notions are enough to interpret a latency graph. The fourth keeps you from making it say what it does not.
Round-trip time
Every point measures a full round trip: the packet leaves the server, reaches the destination and comes back. It is not a one-way travel time, it is the whole loop.
The millisecond scale
The vertical axis is graduated in milliseconds. Read it before the shape of the curve: two identical-looking graphs can cover very different ranges.
Steadiness over the minimum
A low, flat curve beats one with a lower minimum but a jagged shape. Steadiness is what you feel on an SSH session, an online match or an API call.
The return path counts
The outbound and return paths do not necessarily follow the same route. A rising value can come from the return leg, outside our network.
Destinations
Why these four networks
They are public networks, reachable from any operator, and everywhere in what your users do. Probing them gives a readable picture of access quality from our machines. No privileged link is implied: these are measurements, not partnerships.
Cloudflare
In front of a sizeable share of the web: CDN, public DNS resolver, application protection. The round-trip time to Cloudflare approximates that of the sites relying on it.
Search, YouTube, Workspace, Play: the network your users hit most often without thinking about it, and a universal point of comparison.
Netflix
High-throughput video streaming, demanding on path steadiness. Stable latency towards that kind of platform says a lot about transit quality.
Meta
Facebook, Instagram, WhatsApp and their APIs: the traffic of social apps and of the business integrations built on them.
Method
How the measurement is made
Nothing exotic: the tool is called smoke ping, it sends packets and records the time they take to come back. The value lies in doing it continuously, then publishing the result as it is.
Regular probes
From a machine connected to our AS210699 in Paris, ping (ICMP) packets are sent at a fixed interval to a public address of each destination.
A retained history
Every reading is timestamped and stored. History is what makes an anomaly visible: without a past, a single value means nothing.
A Grafana dashboard
The series are plotted in our Grafana. The panels on this page are the ones from our internal monitoring, embedded directly - no screenshot, no retouching.
Published as is
We retouch nothing and reframe nothing to flatter a curve: each panel is taken as it appears on our dashboard, irregularities included.
What the measurement does not say
- It measures the path from our network, not from your connection: your own latency depends first on your operator and your location.
- It relies on ICMP. Some equipment handles ping with a different priority from application traffic.
- It says nothing about throughput or about the load on your applications: a short path has never sped up a badly indexed SQL query.
- It covers four destinations. If your traffic goes elsewhere, measure it yourself from your own machine.
Round out your network setup
The network building blocks our customers most often pair with their servers.
Frequently asked questions
What we get asked most often about these measurements.
It is a repeated latency measurement: instead of a one-off ping, the tool sends packets continuously and plots the history of response times. You then see how steady the path is, not just a value captured at one moment.