That's not something we've specifically seen or spent much time troubleshooting here, so it's hard to say for sure. I'll speculate on a couple of possibilities.

You might want to try tracing to the download site and see what it looks like.

First, an observation. You have your packet loss percentage set to 500% - that means you'll never get full-height packet loss displays. That's a bit of a curious value to use - is that intentional?

It would be interesting to see the whole route to see if any other hops look similar - good job showing hop 9, but we don't see anything else in the middle. This is what's so great about PingPlotter - you can zoom in when you have a question by double-clicking on the time graph and you'll see the route performance at that point in the trace graph.

Possible reasons:

If you're using a big packet size, then the echo replies coming back are different from the final destination than they are from intermediate hops. Intermediate hops always respond back with ICMP TTL Expired (56 bytes), while the final destination will resond back with all the data you sent it. So that means a 512 byte packet size will affect the final destination's performance far more than an intermediate hop if you're near capacity.

Another possibility is that the return route is different (through a different core peer of your ISP) from the final destination, but if that was the problem, your download would mean that was saturating the peer connection to your ISP, which isn't very likely.

ICMP echo replies might have a different prioritization than ICMP TTL expired packets. These rules would need to be applied at the point where the bandwidth saturation was occuring, so it's not entirely likely, but it's possible.

What packet size are you using?

- Pete