For this example, we're assuming the role of a user that's having problems with a broadband connection. What we'll be taking a look at is snapshots of six continuous days worth of trace data. One thing to keep in mind is that if you're doing long term monitoring and want to look at more than the largest default time span on the time-interval graph (48 hours), you can add custom time intervals in the pingplotter.ini file located in PingPlotter's installation directory.

Before continuing, if you're not familiar with how the graphs work in PingPlotter please make sure you've read the introduction to graphs earlier in this tutorial.

One common mistake we see folks make is that they'll trace to their ISP's border router. This is a bad thing. If you're tracing to the border router and your route changes (i.e. they take that router down for maintenance or you get load balanced onto another router) you really have no idea what happened. If you want to keep your traces local to your ISP, trace to an address that isn't going to change on you like you're ISP's mail server. This is actually a good thing to do if you're having mail problems and it's your ISP's mail server going down. Otherwise just pick a destination that you know has a reasonably good chance of always being up. This is a better choice since routes within your ISP can change, and PingPlotter keeps track of those route changes. The cool thing is that you're doing a traceroute here, not a ping, so even if that destination host goes down you can drill down on the timeline graph and see if it's your connection, or if it's just the destination being down (as in all hops but the destination don't show timeouts).

Another problem with tracing to your ISP's border router is that your ISP will not respect the data that you collect this way.  No application targets a border, so they have no reason to trust this data.  For best results, you want to pick a target that is one you use and are having problems with.

Note: For clarity, all the graphs below show us ignoring Hop 1 which you to can do from the View Menu. All the graphs were saved with the File/Save Image command within PingPlotter then converted to .gif for this tutorial.

This first graph shows what the traceroute should look like with no load on the connection, i.e. no downloads, streaming audio, on-line game playing, etc. "What about all that red on the history graph? I thought red was bad?", you ask. Actually red is bad, however before I saved out this graph I double-clicked on the timeline graph to drill down, or zoom-in, and am looking at the data for 9/25/01 at 11:56 a.m. If you look at the top of the graph you see "10 Samples Timed: 9/25/01 11:56:09 AM - 9/25/2001 11:56:32 AM". So basically the above graph's trace for that particular time looks good. However when you look at the timeline graph, you can start to see the tale of woe. What we have here is a really flaky broadband connection. So how do we prove it? Read on.

Just sending your ISP a graph with red lines isn't very convincing. However, when you start zooming in on those sections with timeouts, and send graphs of them as well like this second saved graph, it's pretty obvious the connection's hosed when you can't see out to Hop 2. This is the same time interval as the first graph, just showing a different period in time for trace data.

For our third graph we've got data for early on the second day of our trace. Lots of red, and when we focus on the 3:06 a.m. time period the connection's still poor. You're unable to see out. It's hard to argue with the graph. Also keep in mind that what we're showing here is that the whole timeline graph isn't solid red. This isn't an issue where you accidentally kicked the plug on your router.

For our fourth graph, you can see from the timeline graph's times that we've adjusted the time-interval so we're only looking at 60 seconds worth of data. The trace graph is showing the section of the time-interval graph that we double-clicked on which is 4:07:21 p.m. through 4:07:49 p.m. So what's up with the 60-70% packet loss showing up on the trace graph? Notice that we didn't have timeouts for that whole 28 second period (the right vertical bar is kind of hard to see in this example, but it's at the end of the last time-out there at 4:07:49). Out of the ten samples we're looking at (depending on what hop we're looking at - remember PingPlotter is tracing each hop at the same time so it's logical that Hops 5 and 13 could at this point only be showing 60% loss), roughly 70% of them were timeouts. This is important. When we're looking at the trace data we're looking at those 10 samples we selected and the numbers for those samples, not the whole range of data shown on the time-interval graph! This is not a graph you want to send to technical support. All it's going to do is confuse them.

Ok, so what's up with this last graph? Well, like parents we try to be fair, and what you see is a flaky connection (as you can see from the timeline graph though you'd want to zoom in to be sure where), and trace data (notice the vertical focus bars at the left of the timeline graph that denote the section of data we're looking at) that shows a problem out of your ISP's control. The ten samples we're looking at actually show a problem with the connection between Touch America (tamerica.net) and UUNET (alter.net), or Hops 6 and 7. It's hard to say exactly what's going on there, but more than likely the link between those two routers is saturated. We could try and blame a flaky router at Hop 7, but there isn't any packet loss. It's a good guess that it's the link, not the router, or we'd see the router at Hop 7 dropping packets.

So in summary, PingPlotter allows you to show your ISP where the problem's are. In the these examples, we were essentially showing the whole link going down. However, we could've just as easily seen if the ISP's connection to the Internet was down at Hop 4, because we were tracing to a destination not on our ISP's local network. If there was indeed a problem at Hop 4, we would've had good trace data at Hops 2 and 3, timeouts at Hop 4 and possibly no trace data past Hop 4. If the router at Hop 3 was being flaky, and for instance you saw a lot of packet loss, it's easy to save an image showing just that so you can email it. When sending graphs to your ISP, we've found it's best to send one graph showing data for an extended time period, and then drilling down on the timeouts and sending graphs that truly show them what's going on. PingPlotter allows you to save in .png or .bmp format. We recommend .png because they're smaller.