What can we say about the stability of the network with this information?

Question

While testing network stability with ping, requests timed out before MAX-TIME-TO-WAIT for each reply.

I noted the lines that timed out before 500ms.

COMMAND>ping google.com -n 20 -w 500

Pinging google.com [<google-ip>] with 32 bytes of data: 
Reply from <google-ip>: bytes=32 time=21ms TTL=55 
Reply from <google-ip>: bytes=32 time=13ms TTL=55 
Reply from <google-ip>: bytes=32 time=18ms TTL=55 
Reply from <google-ip>: bytes=32 time=16ms TTL=55 
Reply from <google-ip>: bytes=32 time=10ms TTL=55 
Reply from <google-ip>: bytes=32 time=17ms TTL=55 
Reply from <google-ip>: bytes=32 time=20ms TTL=55 
Request timed out. 
Request timed out. 
Reply from <google-ip>: bytes=32 time=117ms TTL=55
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.
Request timed out. 
Reply from <google-ip>: bytes=32 time=453ms TTL=55 
Reply from <google-ip>: bytes=32 time=23ms TTL=55

Ping statistics for <my-ip-addr>:
    Packets: Sent = 20, Received = 10, Lost = 10 (50% loss), 
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 453ms, Average = 70ms

Thank you for the edit @YLearn, and sorry for that, first ever question on this forum. About the IP addresses, I mistakenly replaced all (using <*.*.*.*>). And about the timeouts, I was keenly observing them and I am certain they all occurred in a blink, which should not happen since -w is set to 500ms, which is humanly noticable. Point taken about testing stability with ping for external networks. Now, my confusion is that what led the requests to timeout before 500 ms. Is there some mechanism by which routers in the path, nearer to the destination, can inform the source about packet loss, resulting in timeout?

Answer 1

We can say that a network with 50% packet loss is not stable at all, at least not stable enough to support healthy internet use. If your link is wireless, this is still too high a loss to be acceptable. If you use only ethernet cables then you are far above what is normal for a cabled ethernet to be acceptable.

In a short answer : Your network is not stable.

What can I infer from what you pasted ? You are using a WiFi network under far from ideal conditions. If youre using cables, you have a malfunctioning switch around (maybe faulty - dried up capacitors in its supply filtering part ?) or your connectors are too rusty. This might be caused by network cards with faulty transformers (the other symptom in this case is that the card connection icon keeps appearing and disappearing on windows - "network cable unplugged" message or something like that). You might have network cable run too long for the ethernet standard, but in that case this is your fault.

BTW, you asked about a tool to check this out. Do you know about traceroute/tracert command ?

Answer 2

What can we say about the stability of the network with this information?

Since you are using a resource outside the network you control as your ICMP echo destination, the best you can say is that you may have an unstable connection. You would need to do additional testing, and possibly with tools other than ping, to make a real determination.

ICMP ping is only a reliable tool for determining unstable connections within a network that you control and know how it handles ICMP. When you get outside your network, the only way it can be used reliably is to show that a connection is stable (i.e. good results would indicate a stable connection).

While output like the above may indicate an unstable connection, it may also be the result of normal operations.

The reason that ICMP is not reliable to identify an unstable connection when used like above is that often ICMP echo/reply messages are given lower priority or rate limited, creating additional latency or dropped messages. Historically, ICMP has been used in a number of different attacks which has caused many providers to implement such measures.

This typically happens most frequently at the destination of your pings, but can also happen anywhere along the path to the destination depending on how the devices are configured.

These limits or rules could be based on a total aggregate amount of all ICMP passing through that device (from any source) or it could be based on the traffic from a single host (or both). They can also use a number of other factors, such as the total amount of ICMP traffic your host has sent in some previous time period, the number of different destinations your host has sent ICMP traffic, and so on.

In this example, the volume of ICMP traffic appears to be fairly low and would ideally not experience such problems when the ICMP traffic is not considered in aggregate with other traffic. However there are a number of ways that the same host may appear to be sending more ICMP traffic than the single ping output provided, which may cause it to exceed limits:

1. The host you are running the ping from is also running additional pings from other windows or processes either with or without your knowledge.
2. If your host is behind a network device that is performing NAT, other hosts on the network could also be sending ICMP traffic. In this case, all the traffic would appear to be coming from a single host.
3. Your ISP could be implementing some form of carrier grade NAT (CGN), meaning that many of their customers can be located behind a single IP. All ICMP traffic from that IP would be viewed as one host by other devices on the internet.

In any case, I do know that Google does limit the amount of ICMP traffic arriving on their servers and this can causes false positives with people who monitor their Internet links by using ICMP to Google servers (I have seen this in at least three different locations in my personal experience).

Is there some mechanism by which routers in the path, nearer to the destination, can inform the source about packet loss, resulting in timeout?

Not really. You can get a response from a router along the way, but those responses will result in other messages than "Request timed out." For example, you may get a "Destination unreachable" message as a response.