Article Rating (9 Votes)
Rate this article
Home » Categories » PingPlotter » Usage

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, what you're looking to do is correlate a performance problem in some other application (ie: web, online game, stock trading, telnet, etc) with graphical data in PingPlotter. PingPlotter data, by itself, can often help to 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 thing 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, that happens when performance problems occur. If you can establish this pattern, then you might be able to determine where this pattern first occurs (ie: which hop or combination of hops) - which can help you understand what's causing the problem, and who to complain to.

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 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, also 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 packets to the next hop just fine. You're looking for intermediate hops that show the same pattern of problems that the final destination has.

Once you've identified the 'culprit' router, you can use that information to start your phone calls / emails to get help solving the problem.

Attachments Attachments
There are no attachments for this article.
Related Articles
How do I set up PingPlotter to use TCP packets?
Viewed 8105 times since Wed, Nov 23, 2005
Destination Unreachable
Viewed 10858 times since Wed, Oct 15, 2003
Why am I seeing route changes?
Viewed 2920 times since Tue, Dec 27, 2005
Time graph packet loss height
Viewed 6921 times since Thu, Oct 30, 2003
E-mail us