Packet loss not seen with ping -t
A 'pure ping' using -t switch shows no problems, but PingPlotter shows many packet losses. What would cause that?
If the final destination is showing different results than ping -t, then here are some possibilities:
- 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.
- 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 sequnce of PingPlotter and then the version number. You can change PingPlotter to be the same as Ping by creating a text file with the same thing that PING sends (i.e.: create the file with abcdefghijklmnopqrstuvw in it), and then go to Advanced options and change the packet cargo to use this file. 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 and extraordinary bytes sequence that stimulated the packet loss. This is worth trying though since it's quite easy to do.
- 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.