myip
🇬🇧 EN

Online ping test

Real ICMP echo requests are sent from our server, one packet per second. Replies appear here as they arrive.

What ping measures, and what it does not

Ping sends a small ICMP Echo Request to a host and times how long the Echo Reply takes to come back. That is the entire mechanism. It was specified in RFC 792 in 1981 and the tool itself was written in an evening in December 1983, which tells you something about how little has needed to change since.

The number it produces is round-trip time: there and back, including the time the far end spent noticing the packet and answering it. It is not the time to load a page, not a measure of bandwidth, and not one-way delay — you cannot simply halve it, because the return path is often not the same path as the outbound one.

One thing to be clear about before reading any result on this page: this test runs from our server, not from your computer. It measures the route between our network and the host you named. That is exactly what you want when you are asking "is this host up and reachable from the internet at large", and exactly what you do not want when you are asking "why is my own connection bad" — for that, the only meaningful ping is one you run yourself, from the machine having the problem.

Reading the numbers

Four values matter, and people usually look at the wrong one first.

Latency (minimum and average)
How far away the host is in network terms. Use the minimum as the honest floor of the path — it is the run where nothing was queued anywhere. The average tells you what to expect in practice.
Packet loss
The single most damaging figure. Anything above zero to a well-run host deserves explanation; a few per cent is enough to make video calls stutter and file transfers collapse, because loss makes TCP back off hard.
Jitter — the spread between minimum and maximum
Variation matters more than absolute delay for anything interactive. A steady 90 ms is comfortable for a voice call; an average of 40 ms that swings between 10 and 300 is not, because the receiving end has to buffer for the worst case.
TTL of the reply
Not a timing value at all, and quietly useful — see below.

What a normal latency looks like

There is a hard physical floor here, and it is worth knowing so that you stop expecting the impossible. Light in optical fibre travels at roughly two-thirds of its speed in vacuum, about 200,000 km per second, which works out at about 1 ms of one-way delay per 100 km of cable — and cable never runs in a straight line.

If a host in your own city answers in 120 ms, the distance is not the explanation. Either the traffic is taking a long way round — routes between neighbouring networks sometimes meet only in another country — or something along the path is congested.

No reply does not mean the host is down

This is the most common misreading of a ping result, and it costs people hours. A timeout means one of several things, and only one of them is "the machine is off":

The practical rule: ping proves reachability when it answers, and proves nothing at all when it does not. If you need to know whether a service is actually working, ask the service — check whether its port accepts a connection, or see what the web server really returns. A host that ignores ping while happily completing a TCP handshake is not broken; it is normal.

The TTL field, and what it gives away

Every packet carries a time-to-live counter that each router decrements by one, so a packet caught in a loop eventually dies instead of circling forever. Operating systems start it at predictable values: 64 on Linux, macOS and most Unix systems, 128 on Windows, 255 on a lot of network equipment.

Subtract the TTL you see from the next value up and you have the number of routers the reply crossed. A reply with TTL 57 started at 64 and crossed seven hops. It is a rough hop count and a rough hint at the far end's operating system, obtained for free, and it is occasionally the fastest way to notice that traffic you thought was local is crossing fifteen routers to get where it is going.

Latency, bandwidth and the thing people confuse

Latency and bandwidth are independent, and conflating them is behind most "we upgraded the connection and it did not help" stories. Bandwidth is how much fits through the pipe per second; latency is how long one thing takes to arrive. A satellite link with enormous capacity still has 600 ms of delay, and a modest connection to a nearby server still feels instant.

Which one you should care about depends entirely on the task. Downloading a large file is a bandwidth problem. A voice call, a remote desktop, a game, or a page that fetches forty small files in sequence — all latency problems, because each one waits for a round trip before it can proceed. This is why doubling a connection's speed often changes nothing about how fast a website feels.

There is also a case where high ping is not a fault at all: bufferbloat. When a link is fully occupied — a large upload, someone else's backup — packets queue in oversized buffers and latency climbs into the hundreds of milliseconds while throughput stays perfect. If ping is fine when the line is idle and terrible when it is busy, that is what you are looking at, and the fix is queue management on your own router rather than anything at the other end.

A workable order for diagnosis

  1. Ping the destination. An answer with sane latency and no loss means the network path is fine and your problem is above it, in the application.
  2. Ping something known-good nearby — a large public site. If that is also slow or lossy, the problem is your side, not the destination.
  3. Compare from elsewhere. Run this page's test, from our network, against the same host. If ours is clean and yours is not, the difference is on your path — your provider, your line, your equipment.
  4. Check the service, not just the host. A responding host with a dead service looks identical to a healthy one from ping's point of view.
  5. Look at what the name resolves to. Slow or wrong answers are often a DNS problem misdiagnosed as a network one, and the address you are pinging may not be the address the application uses.

Why this test is limited on purpose

We send a small number of packets, one per second, and stop. That is enough to see latency, jitter and loss, and it is deliberately not enough to be useful to anyone wanting to point traffic at somebody else. Private and reserved ranges are refused outright — an address inside your own network is unreachable from ours by definition, so a check against it could only ever produce a misleading answer.

Frequently asked questions

What counts as a good ping?

It depends almost entirely on distance. Under 10 ms means the host is in your city or region, 10 to 40 ms is the same country, 70 to 120 ms is normal across an ocean, and 500 ms and up means a geostationary satellite link. Light in fibre covers about 100 km per millisecond in one direction, so a transatlantic round trip physically cannot be much under 60 ms no matter what anyone sells you.

The host does not answer ping. Is it down?

Probably not. A very large number of servers and firewalls drop echo requests as a matter of policy while serving real traffic perfectly, and routers deliberately limit how many pings they will answer because they process them in software. Silence proves nothing. If you need to know whether a service works, check whether its port accepts a connection or what the web server actually returns.

Does this measure my own connection?

No. The packets are sent from our server, so what you see is the path between our network and the host you named. That is the right test for "is this host reachable from the internet", and the wrong one for "why is my connection slow". For your own connection, ping from the machine that has the problem — then compare the two results, because the difference between them is exactly the part of the path that is yours.

What is the difference between latency and bandwidth?

Bandwidth is how much data fits through per second; latency is how long a single exchange takes. They are independent. A satellite link can carry a huge amount of data and still have 600 ms of delay, which is why upgrading a connection often makes downloads faster while changing nothing about how responsive a website feels. Calls, remote desktops and games are latency problems; large downloads are bandwidth problems.

Why does packet loss matter more than a high ping?

Because TCP treats loss as a signal of congestion and reduces its sending rate sharply when it sees it. A steady 200 ms with no loss is workable for most things; 30 ms with two per cent loss produces stuttering calls and transfers that never reach full speed. Loss on an intermediate hop is often harmless, though — many routers deprioritise packets addressed to themselves while forwarding everything else perfectly.

My ping is fine normally but terrible when someone is uploading. Why?

That is bufferbloat. When a link is saturated, packets sit in oversized queues on your own router or modem, and latency climbs into the hundreds of milliseconds while throughput stays perfectly good. Nothing is wrong with the remote host or your provider, and the fix is queue management — the modern algorithms are usually listed as fq_codel or cake — on the device at your end of the line.

What does the TTL value in the result tell me?

Each router that forwards a packet reduces its time-to-live by one, and operating systems start it at predictable numbers: 64 on Linux and macOS, 128 on Windows, 255 on much network equipment. Subtracting what arrived from the nearest starting value gives you the number of routers the reply crossed, plus a decent hint at the far end's operating system.

Can I ping an address on my home network from here?

No, and no site can. Private ranges such as 192.168.x.x and 10.x.x.x exist independently inside millions of separate networks and are not routable across the internet, so a request from our server could never arrive at your device. We refuse them explicitly rather than returning a timeout that would look like a real result.

Related checks