Knowledge Base
How do I pinpoint the problem?
Question
What kind of conditions should I be looking for in PingPlotter? I get occasional timeouts in applications I'm using - how do I know what's causing those problems?
Solution
Ideally, you're looking to correlate a performance problem in some other application (i.e.: web, online game, stock trading, telnet, etc.) with graphical data in PingPlotter. PingPlotter data, by itself, can often help track down problems, but most providers need you to complain about some real service problems before they will act on it. If you can say 'I normally play X game in the evening, but I keep getting disconnected. Look at this PingPlotter data I collected during one session. See the problem here?', that can be a call to action for them, rather than just a random data point.
When you're expecting to experience a problem, start PingPlotter and trace to the target of the service you'll be using (example: if you're going to be using telnet to access your remote web server, run PingPlotter against that server).
Now, go about your business doing whatever you normally do. When (and if) you experience a problem, switch over to PingPlotter and create a comment for the time period it happened (See the 'Creating a comment or note' in our Getting Started Guide for instructions on how to do this).
As you run into more problems, continue to collect information and create comments. Ideally, you'll have some periods where there were no problems and some periods where there were problems. Sometimes, this might take multiple days to get both - just keep PingPlotter running constantly (see our knowledge base for tips on long-term monitoring).
Your mission here is to locate a pattern, recognizable in the PingPlotter graph of the final destination,
Look for patterns in the final destination - packet loss periods, latency. Put comments on them when they happen. Then, go back and look at previous hops to see if you can find things that happened in common at the times when you're seeing problems.
A good technique to locate which hop is the most likely problem point is to set 'Samples to include' to an appropriate number based on the network disturbance you're seeing. Double-click on the time graph for the final destination to focus the upper graph on that period. You'll see a 'focus rectangle' that shows the time period you're looking at - change 'Samples to Include' to make that time period big enough to get a good sampling of the problem - 50 or more samples is recommended in most cases, but if your disturbance was very short, then a smaller number might work.
Once you've focused the time graph, the upper 'trace' graph will show the statistics for that time period for all hops. Look for the first hop that is showing the latency or packet loss problems you're seeing at the final destination. Turn on time graphs for the intermediate hop you think is causing the problem (double-click on the hop number to toggle the visibility of the time graph) and then compare the packet loss and latency periods. It's good to also turn on the previous hop to really show where the problem is starting (see our Getting Started Guide for more details on this technique, and our Voice over IP troubleshooting guide has a bunch of examples of this technique).
Keep in mind that some intermediate hops might be showing packet loss or latency that isn't showing up in the final destination. That 'red herring' data is due to the nature of traceroute - some intermediate hops down-prioritize their responses to traceroute packets, although they forward
Our Common Network Problems article (which provides an image lineup of "the usual suspects" that cause network issues) can be a great help in narrowing down the cause of your problem.
Once you've identified the 'culprit' router, you can use that information to start your phone calls/emails to get help solving the problem.