I'm wondering what a maximum (practical) ping response time might be. As far as I know, there isn't a max defined anywhere (TTL, but that's hops, not time). As I think about it, I'm not sure I've ever seen a ping response time of more than a second or so. But as far as I know, there is nothing to stop a remote host from waiting (or being really busy) and not sending the response back for a few seconds.

As a simple data point, I just pinged a number of servers around the world and the worst time I could find was 350ms.

  • 3
    If you could travel back in time and have the great privilege of working with some badly congested 64kbps WAN links you could see responses of 30000ms more often than you could ever want. ;-) Jun 2, 2010 at 6:04
  • 1
    @Graeme +1. I've seen responses like that too, but from broken packet shaper boxes that seemed to be queuing forever when things got congested. It was not uncommon for me to get ping responses as much as 10 minutes later. Yes, that is 600,000 ms. That sort of thing should be outlawed. And this was as recently as 2008. Jun 2, 2010 at 6:24
  • @Graeme Donaldson, it's not possible, pls see me answer
    – Berkay
    Jun 2, 2010 at 6:27
  • @Berkay, I assure you it happened. Its not worth arguing though, since this was easily 9 or 10 years ago and I almost certainly wouldn't be able to reproduce it now, even if I wanted to. Jun 2, 2010 at 8:46
  • For what purpose do you need to know this (i.e., are you looking at configuring something to raise alerts on extended ping times) - or is it just idle curiousity? :-) It will probably affect the answer(s) [i.e., theoretical as currently being discussed] or practical advice.
    – Chris J
    Jun 2, 2010 at 12:35

5 Answers 5


I'm wondering what a maximum (practical) ping response time might be. As far as I know, there isn't a max defined anywhere (TTL, but that's hops, not time).

Theoretically, the time between echo request and reply can be long. From a quick glance at RFC 1122 I don't see any formal constraints here.

Practically though, there's a threshold value after which lack of reply will be treated as no reply at all (timeout). The specific value depends on implementation:

  • In Windows it's 4 seconds.

  • With iputils implementation of ping it seems to be 10 seconds - not sure about it, as it's not stated in the man page, but the code says something like this:

     #define MAXWAIT         10              /* max seconds to wait for response */

Ping responses longer than that are equivalent to no responses at all. So, I think it's safe to assume this to be the practical limit.

One thing to note - I'm talking here about ICMP only. If you meant some other "ping" (for example delay between some application-specific request/response), it will probably differ completely.


It's worth noting that an implementation of RFC1149 achieved this ping time:

64 bytes from icmp_seq=0 ttl=255 time=6165731.1 ms

...which is about 102 minutes. I've yet to see a longer response time.

  • 1
    That's funny, but I guess I should have specified ping times for an electronic network, not one built from carrier pigeons :)
    – DougN
    Jun 2, 2010 at 12:06

The maximum desired ping response time depends on the application spread. VoIP can only handle 200ms or so (depending on Codec) but most HTTP aplications are built to handle a lot more than that. You also need to remember that the service provider (or your network admins) can implement QoS that will put ping into a lower priority bucket.


The default for Windows might be 4 seconds, but it can be longer. I know vbforums refuses ICMP traffic. Each timeout took 10 seconds.

C:\Users\FredFlintstone>ping www.vbforums.com -w 10000 -n 2

Pinging www.vbforums.com [] with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),

Given the following

PC --- RTRA --- RTRb --- RTRC --- RTRd --- Server

The response time depends on transit times between each hop, assuming all links are active, all routers accept / forward ICMP, and Server accepts and responds to the ICMP.

If Server has code that intercepts ICMP traffic, and puts it into a queue of responses to send later, the response time, theoretically, could be anything. At that point the PC sending the ping would be dependent on it's internal timeout.

Overall MHO is that pings are pretty much worthless. It is akin to looking at Where is Waldo pictures for 1 ms. each and thinking you know something.

Pings are normally low priority traffic on the backbone. Successive pings, and for that matter most traffic, and associated responses may or may not take the same route. As I posted in my comment above, recreational pinging and ping-then-do is getting us all closer to the day when the ISP's look at their traffic statistics and say, "Hey, I can regain 2% (or more) of my bandwidth by shutting off ICMP".


As I think about it, I'm not sure I've ever seen a ping response time of more than a second or so.

In Linux, the ping command has an interval between echo-requests of 1 second. If an echo-reply is not received in that interval of time, the packet counts as loss. The knob -i of ping command can be used to increase interval time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.