Hi, Susan.

Actually, there is less problem here than you might think there is.

The general technique for use of PingPlotter is to look at the final hop (or the last hop that is responding well, if the final destination isn't available like what you're seeing in the attached graph). If you see problems at that hop, then look back to earlier hops to find out the culprit for those problems. Any problems that occur at any intermediate hops that do not appear at the final destination, though, are non-issues.

Most of the graph problems we see hare are probably (I can't say for sure since you didn't turn on the time graph for hop 10), are not at the final destination. The "jitter" you see at hop 8 doesn't look like it shows up at hop 9 or 10, so that's an oddity of hop 8. The packet loss at hop 2 doesn't show up at hop 4, so that's an artifact of hop 2 that isn't affecting your downstream experience.

We talk about this technique here:

http://www.nessoft.com/kb/47

Also, we talk about how intermediate hop performance doesn't matter here:

http://www.nessoft.com/kb/24

Honestly, I don't see an obvious problem in the graph you attached. I'd want to see the graph of hop 10 (and ideally, I'd turn on TCP packets and try and get a trace graph of uswest.battle.net port 6112), but it looks pretty good.

Also, you'll want to correlate problems with "incidents" (lag, dropped connections, etc) - we discuss that in the first article listed above.

- Pete

Hop 8 (12.123.13.174) is showing some jitter, but