Round-trip time
Measures the TCP handshake time to a host, four attempts in a row. This is what every web-based ping measures: a real ICMP ping needs privileges a web application does not and should not have.
The measurement runs from our server, not from your network. The absolute numbers depend on where we sit; compare hosts against each other rather than against a ping from your own terminal.
This is the time a TCP handshake takes between our server and the host you name, measured several times so you can see the spread as well as the average. It is deliberately not ICMP ping: sending real ICMP requires privileges an application should not hold, and the honest thing is to say which measurement you are showing rather than to label a TCP timing as "ping".
The practical difference is small but worth knowing. A TCP handshake involves the target's network stack rather than only its kernel's echo path, so the figure is typically a millisecond or two higher than ICMP and, in return, tells you something ICMP does not: that the port is actually reachable. Hosts that drop ICMP entirely — increasingly many — measure fine here.
Best is the closest you will get to the pure network distance, with no queuing.
Average is what your application will typically experience.
Worst and the spread between attempts matter more than the average for anything interactive. A stable 90 ms is a better connection than one that alternates between 20 ms and 200 ms, even though the second may average lower.
Roughly: under 50 ms is close, 50–150 ms is a different country, 150–300 ms is another continent, and above 300 ms suggests a satellite link, a badly routed path or an overloaded host.
Latency is the part of proxy performance you can measure before you buy, and it compounds: every request pays it twice, once to the proxy and once onward to the target. A proxy 200 ms away does not make your scraper 200 ms slower — it makes every one of its thousands of requests 200 ms slower. Distance is the floor, but it is not the whole story: an oversubscribed endpoint adds queuing delay that shows up here as a wide spread between attempts rather than a high minimum.
Measurements are taken from our server, not from your machine, so the figure describes the route from us to the host. Use it to compare hosts with each other rather than as a prediction of what your own connection will see. Like the other two tools that reach out from our infrastructure, this one resolves the target before judging it, refuses private and reserved ranges, and is rate limited.
Not in the ICMP sense. It measures the time to complete a TCP handshake, because sending genuine ICMP packets requires system privileges a web application should not have. The result is a millisecond or two higher and additionally proves the port is reachable.
Under 50 ms is excellent and usually means the host is geographically close. 50–150 ms is typical across a country or continent. Above 300 ms is noticeable in anything interactive and suggests distance, poor routing or an overloaded target.
Variation between attempts is jitter, and it comes from queuing along the path or on the target itself. A wide spread hurts interactive traffic more than a uniformly higher average does, which is why the spread is shown rather than just the mean.
No, from our server. That makes the numbers comparable between hosts, which is what you want when choosing between them, but it is not a prediction of what your own connection will experience.
No. Latency is delay; throughput is volume per second. A satellite link can move large files respectably while being unusable for anything interactive, and a low-latency link can still be bandwidth-starved.
Not necessarily. The port we try may be closed or filtered even though the host is running. Check which ports answer with the port scanner before concluding the machine is offline.