Can you create another picture that includes the timegraph for hop 4 also (double-clicking on hop 4 will show that graph). Sometimes, you can correlate lost packets in an intermediate hop and latency in a final-destination hop, but that starts to become difficult as the "noise level" of the intermediate hop increases.

In the knowledgebase article I referenced, we talk about correlating real-world application performance against PingPlotter data. This is an important thing to do. Run PingPlotter against that host and then correlate the complaints against users against this data. You can right-click the time-graph in PingPlotter and use the option to create a comment at a particular point in time.

See if you get packet loss to your final destination with PingPlotter at the same time you're getting complaints from your users. If you're *NOT*, then the problems your users are seeing might be server application based, or the packet loss might be protocol dependant.

You can check for server application based problems by looking for another network to connect to. If you get better performance when connecting via a different network, then you can mostly elminate the server application as the bottleneck.

Do you *ever* see packet loss in PingPlotter ot the final destination? If you do, you might be able to correlate these packet loss / latency spikes with earlier hops by turning on the time-graphs for the earlier hops and then mentally "subtracting" the normal packet loss and latency you're seeing. You're trying to determine where the problem originates, and although the "noise level" on the intermediate hops is higher than we'd like, you may still be able to extract a pretty good picture from this data. If you can't correlate final-destination packet loss/latency with your user's horrible problems, though, then PingPlotter likely isn't going to be a lot of help in determining where the problem is.