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.
It's worth noting that an implementation of RFC1149 achieved this ping time:
...which is about 102 minutes. I've yet to see a longer response 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:
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.
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.
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".
In Linux, the
pingcommand 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.