The data you sent me actually looks *quite* good. The hop 1 data does have a pretty wide range of latencies, but that's often normal for hop 1. Hop 2 and 3 look solid and consistent (except for one spike at 1:20ish PM - and an isolated spike often doesn't indicate a problem).

You always want to start at the final destination and look for periods of problems. If there is any problem at the final destination, then you look back at upstream hops for the same problem shown in those hops. The first hop that shows the same problem is likely close to the source of the problem. The 1 spike you had at 1:20pm originated at hop 1 (that's the first hop that shows the same spike), so it's pretty likely that something between your computer and that hop is the cause of that spike. This spike is only one sample in length, though, and isn't severe, so this in itself isn't any reason for concern.

My in-brief analysis of the data is that there isn't a latency or packet loss problem over the period of time you collected data. Were you experiencing any poor application performance during this period?

Based on this data, I would suggest that you ignore hop 1 in your analysis unless there is a problem in a downstream hop. You also should correlate other problems with this data. If you're playing a game and getting poor performance in-game, then look at the PingPlotter data you're collecting concurrently to see if PingPlotter shows any numbers that back up your feeling of poor game performance. Maybe some other application is performing poorly (email, http, ftp, etc), or your network just feels generally sluggish - correlate that with PingPlotter latency and packet loss data.

Once you've found this period where you've correlated symptoms with numbers in PingPlotter, then it's time to look at PingPlotter to find the likely culprit. PingPlotter might have a certain "signature" that you can recognize (packet loss / latency spikes - I use the term "signature" somewhat loosly here, just as something that you can recognize when you see it). Once you identify that signature, then you might not need to correlate PingPlotter numbers with real-world symptoms, and you can just run PingPlotter 24X7 to look for the signature. You can then troubleshoot with PingPlotter looking for that signature, and trying to determine the cause of the problem.

The data you sent me doesn't have either side of the equation here, however. It doesn't have the symptoms (ie: description of sluggishness or similar application problem) or any "signature" data that I can recognize. In general, I'd say that your PingPlotter data looks quite good (if you ignore hop 1, which you *should* do in the case of the data you sent me, I think).

I would suggest as the next step that you collect data continuously - and look for a specific performance problem that feels like packet loss or latency - and then look to PingPlotter for the hard numbers that will back up your claims so you can bring that to your ISP.

Feel free to respond here or to the support address with any ongoing questions or any followup data that you'd like to add to the story here.