Interpreting PingPlotter Results
Common Network Problems
Here you'll find a lineup of the most common (and sometimes uncommon) PingPlotter results. We've assembled this list to act as a sort of "perpetrator lineup," so you can match your results against what you see here and get more specific information about what you may be encountering.
41ms round trip latency with no packet loss? You really can't ask for results much better than this!
The packet loss at hop #2 and hop #7 is nothing to be concerned about — some routers just don't prioritize timed-out ICMP requests very well. As long as this packet loss doesn't have a negative effect on the final destination, you don't need to worry about it.
For more details, see:
Every network has limits, and running at the limit is not necessarily a bad thing. This graph is an example of a network that's running great but then gets saturated/overused.
The distinct parts of this pattern are that latency and/or packet loss occurs at a bandwidth-limited point (often the connection between you and the ISP), and it starts and stops pretty abruptly. If you have a "fat pipe", the latency jump is probably not as big as this example.
The effects to the rest of the network are pretty big, where everything is fine and then suddenly web pages take forever to load, movies buffer, VoIP calls get garbled and it feels like 2002 again with your slow network.
In PingPlotter, bandwidth saturation appears in many forms. One distinct pattern is the Sawtooth. This pattern is a strong (like really really strong) indicator of bandwidth saturation.
There are a few possible solutions to this problem:
- Use less bandwidth.
- Buy more bandwidth.
- Get a device between you and your ISP that limits overuse by big consumers (throttling, but the good kind).
- Put up with it.
If possible, it's nice to correlate the activity on your network with these results so you can act to minimize the effect (maybe you can download that ISO late at night when no one is watching a movie).
Bandwidth saturation can come from two directions - overuse, or undersupply. If this happens regularly and you can't figure out why, you might want to get with your provider to have them help you troubleshoot.
For more details, see:
Bandwidth saturation happens everywhere, and honestly, there are many manifestations of it. Here's an example where there's some packet loss nearer the far end.
When you see situations like this that are chronic and affecting you regularly, it may be best to contact the provider at the far end, if you have a relationship with them.
For more details, see:
Wireless networks are not always reliable - if you're seeing consistent packet loss at hop 1 (your wireless router/hub) and you're connected to your network with 802.11 wireless, then your wireless connection may be the culprit.
Wireless connections are almost always recognizable (vs a wired one) because there is a non-zero latency even inside your own network. Sometimes, this is 1ms - sometimes it can be as high as 4 or 5 ms normally, and sometimes you get regular latency as high as 250-400ms.
If you're seeing that and you can somehow connect your computer to a wire, it may make a big difference in your network experience. If that's the case, sometimes changing wireless channels can help (from your wireless router) or even upgrading your wireless router to a newer one.
If you suspect this is happening to a wireless hardware device (like a Blu-ray player or similar) and your computer's network latency/packet loss looks just fine, you may want to try tracing from your computer to that device (find its IP address in the setup menu for the device). If you see results like the graph here, you'll probably have a way better experience with a wire.
Bad Hardware on Local Network
Marginal wiring or failing hardware in your own network happens more often then we may think. The good news is that once you've found the problem, you can often actually fix the problem. In this case, you know it's inside your own network because hop 1 is your router, and any device with a 0ms normal latency is most likely pretty close to you.
In this case, the most likely culprits are a network cable, your switch/hub/router, a network card in your computer, or a similar piece of hardware or cable. Look for anything between you and the router at hop 1.
This could also be a bad power supply (especially if the red periods are just about as long as it takes to reboot a device), or even bad/noisy power or bad grounds.
One way of isolating the problem is to trace to a target inside your own network (another computer, your TV, Roku, or anything else you know the IP address for) and see if the problem shows up then. If you can trace to another device and the problem doesn't happen, you can eliminate any hardware or wiring that's involved in that scenario and focus on other spots.
For more details, see:
Internet Service Provider Bad Hardware
Low levels of packet loss at the first hop inside your provider's network can sometimes be indicative of a connection that's struggling to maintain service. This might be because of noise on the line or marginal hardware. Water in a junction box is one example, or maybe a bad splitter or terminator on a cable modem line.
This diagnosis is valid when there is consistent packet loss pattern at downstream hops starting inside your provider and following through all the way to the final destination. If you're only seeing the packet loss pattern at a single hop, then that's not indicative of an issue.
In cases like this, your ISP can often measure the signal quality from their data center and may be able to see the problem from their end, too.
Low levels of packet loss like this can sometimes make your job harder because if your provider doesn't see the problem, they may not believe there is a problem at first. If that happens, then try looking for time-based or weather-based problems that might help accentuate the pattern. Also, make sure you're keeping track of the effect this problem is having on your experience — i.e. you're losing connection or having freezing or buffering.
For more details, see:
Destination Address Unreachable
The fact that the graph is this screen shot is returning a "Destination Address Unreachable" message doesn't necessarily mean that the target website is down. One of the routers between the computer running PingPlotter and the destination is not passing through ICMP echo requests or not allowing ICMP TTL expired packets to return.
The first thing that should be tried here is to see if switching to TCP or UDP packets returns any results.
Even if the target here doesn't respond to any of the different packet types - the information from the rest of the route can still be useful. Most chronic reoccurring network problems (more than 90%) happen closer to home — like in hop #1, #2, or #3 — all of which can still easily be monitored from here.
For more details, see:
No Hops Showing
If you're seeing symptoms that are shown in the above screenshot, odds are you probably have some kind of network firewall software installed on your computer. Many of these firewalls use "by application" network blocking, meaning you need to flag specific applications that you want to access the internet.
The fact that none of the intermediate hops seen in this screenshot are returning any information tells us that the culprit here is something close to the computer that is running the trace. This could be firewall software on the computer itself, a firewall or router between the computer and the first hop or a handful of other things.
The packets that are being dropped are ICMP TTL Expired packets returning from the internet back to you.
For more details, see:
This screenshot is taken from a computer that is actually running PingPlotter with through Parallels. Both VMware and Parallels (for macOS) have issues when the VM is set up using NAT, because of shortcomings in their network stack (which results in only the final hop showing up, as shown in the screenshot). If you switch your VM network configuration to "bridged" mode, the full route should display.
For more details, see: