Knowledge Base

PingPlotter doesn’t match command line ping

Question

A 'pure ping' (command line) using -t switch shows no problems, but PingPlotter shows many packet losses. What would cause that?

Solution

First, make sure that you’re comparing the results from the final destination of your trace in PingPlotter with the “pure ping” results. When a device is an intermediate hop in a route, the request it’s receiving is expired (the TTL on the packet equals 0). When a device is being targeted directly, the request it’s receiving isn’t expired (the TTL doesn’t equal zero). Some devices will down prioritize TTL expired requests - a concept we cover in more detail here. If you're directly pinging an intermediate hop (with command line ping or any ping tool), it's really, really common to have PingPlotter show a different result (because PingPlotter is actually targeting your final destination and getting results for the intermediate hop as a side affect - it's timing the error message, not the ICMP echo reply that happens when you directly target the intermediate hop).

If the final destination is showing different results than ping -t, then here are some possibilities:

• Because PingPlotter sends out packets for every hop, PingPlotter may be saturating your bandwidth, while ping -t doesn't (because it only sends out a packet to the final destination). Make sure your packet size is set to 56 bytes or less (lower = less bandwidth), and that your packet send delay is at 50 ms or higher (higher = less bandwidth).
• The packet size could be different, and that different packet size in Ping Plotter may be causing some packet loss. Note that this is a problem with the router, not PingPlotter, but you can change the packet size to something smaller than default to see if this affects it. Go here to see how to change the packet size. A bios update to your router or broadband device might help this - check with your hardware manufacturer for a new firmware version. Note that ping -t (no options) will send out packets with 32 bytes of data, plus 28 bytes of header, so set PingPlotter / MultiPing to 60 byte packet size to be equivalent.
  
• Having multiple simultaneous outstanding ICMP echo requests may be causing a problem in one of the routers. This isn't too common, but is almost always traced back to a router/device on the local side (check with your hardware manufacturer for BIOS/firmware updates). See the FAQ entry on this topic if you want PingPlotter to do one outstanding request at a time.
  
• In some very isolated cases, we've seen a difference in packet loss based on the contents of the packets. Ping -t uses a repeating sequence of 'abcdefghijklmnopqurstuvw' while PingPlotter uses a repeating sequence of PingPlotter and then the version number. This is kind of a long shot, though, as in all cases where we've seen this make a difference, PingPlotter was used to simulate an extraordinary bytes sequence that stimulated the packet loss.
• Sometimes if there is an oscillating route where the route length changes regularly, PingPlotter might not properly detect it, and might show packet loss. To check if this is the case, go to View -> Ignore First Hops -> Ping Final Hop Only. If this makes a difference, feel free to contact us and we'll help determine if there is a solution.

Most often, the problem is because of your router does not like the way PingPlotter sends out many packets at once. If this is the problem, another solution to this problem may be to change to the UDP or TCP packet types. Give those methods a try and see if your results become more reliable.