Hi, Eric.

There is a ton of lost packets and latency at the intermediate hops, but ... those hops are passing downstream data just fine, so the fact that you're seeing packet loss here means you pretty much have to ignore these hops in your analysis (well, at a minimum you need to ignore the packet loss and latency that occurs normally).

We talk about this a little bit here:

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

and a bit more obliquely here:

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

Ideally, what you're looking to do is correlate a performance problem in some other application (ie: SSH / SFTP / VPN). Most of these protocols use TCP, so you might set up PingPlotter's TCP packet type with the port of the application you're using (ie: port 23 for SSH) and then run PingPlotter while you're using that application.

When you experience slowness, go to PingPlotter and make a note of it with comments (or, if you have the time, you might analyse things right then).

What you're trying to do is determine if there's a pattern, recognizable in the PingPlotter graphs, 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.

The huge packet loss numbers you're constantly seeing at the intermediate hops are not causing the problem - since that occurs all the time, even when performance is OK. The fact that those hops respond poorly makes it a bit more difficult to troubleshoot, but certainly not impossible.

Look for patterns in the final destination - packet loss periods, latency. Put comments on them when they happen. Then, go back and see if you can see things that happened in common at the times when you're seeing problems. Once you've identified that, use the route information and turn on some of the other time graphs to find the first hop where it occurs. That's a likely area where you'd start with phone calls / emails for more help.

- Pete