PingPlotter Getting Started Guide
Finding the Source of the Problem - Cont.
Let’s apply and build on what we've learned and dig deeper.
The black line on the Timeline Graph shows you the latency over time. As you zoomed in on the graph earlier you saw that really what you’re seeing is pixel-wide entries that represent the roundtrip time, or latency for the host/device who's Timeline Graph you’re looking at.
Red, on the other hand, represents packet loss. PingPlotter didn’t get anything back. We have numerous articles that go over different reasons why you could see packet loss in the Knowledge Base at www.pingman.com/kb. Our goal here is to help you understand at a basic level how PingPlotter can help you figure out why that loss is happening.
Packet loss, of course, isn’t the only thing that can cause poor performance for your particular application. The other big factor is latency. For online games, for instance, latency is a killer. Let’s review our sample data, and look at a trouble spot so we can learn more how to interpret what PingPlotter gives us that no other tool can.
Let’s look at the time period around 11:30 am on March 21, 2015. Let’s take the approach that we were browsing the web at that time and were running pcAnywhere into our computer at work. The pcAnywhere session goes to pot.
- Set "Focus Period" to 30 minutes (we're using 30 minutes here because it's easy to see the focus period on the 24 hour graph).
- Change the Timeline Graph scale to 24 hours (remember: right-click then pick 24 hours). Scroll timeline until you can see the 2/13/2004 8:00a time period on the graph.
- Take a look around at that time between 8:00 pm and 12:00 am. Double-click a time period somewhere between 8:00 and 12:00. You'll notice the focus lines appear on the time graph, and the upper graph will show packet loss.
- Wow - look at that packet loss! 19% at hop 4 and hop 5. Notice how the packet loss begins at hop 4, and then all the downstream hops also show high packet loss. This is a strong (compelling, in this case) indicator that hop 4 (or the link between hop 3 and hop 4) is the reason we're seeing packet loss.
- Notice the packet loss trending over time. This indicates some kind of time-based load problem. Also, the fact that the packet loss starts at the junction point between rr.com and alter.net indicates a possible problem at the connection between these two providers. It's possible that rr.com doesn't have enough bandwidth to service needs.
- Let's turn on a couple more timeline graphs. Double-click on hop 3 and hop 4. Notice the difference in packet loss. More evidence to suggest there is a problem related to these hope. All this support that idea that we should contact the people in charge of those hops and find out if they can help us solve this problem!
- This data highlights a number of other problems as well. Feel free to scroll through the data and look for additional problems (see the packet loss going through all the hops around 4:45pm? What do you think the source of this problem is?). Note that this data is at least partially false, and it shows a number of problems in the same time period that may not be realistic.
- Try zooming in on a problem-period by changing the timeline graph scale to something lower. When you see an interesting period, double-click on it to "focus" it, and then change the timeline graph scale to zoom in or out. This gives you a close-up view of the data with more detail.
Now it should be noted that spikes on your graph may not be really high latency. A spike in the graph is high latency for that period displayed on the graph. The Timeline Graph auto-scales itself, so to see what that high spike is you need to look to the left-most part of the Timeline Graph. In this case the value we’re looking for is 220ms.
This was a really quick example of moving around within PingPlotter and digging out information about not only what’s going on with a connection, but really focusing in on a problem. Let’s move on now and talk about collecting this data over time and preparing a good case for your ISP (or someone able to solve this problem!).