Hi, What a great utility, been playing with it for hours (days even) but can anyone explain why the last hop on the following graph shows a distinct rise in latency when I'm downloading from a totaly unrelated site. It appears to be effected to a far greater extent than any of the previous hops?
I tried this with various different destinations and got similar results.

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

I'm working on producing some more meaningful pics and will include links to data files.

In the meantime you might like to know I set the packet loss percentage to 500% so that it just fills the green area on the horizontal graphs without getting too much in the way on the top graph. Also I have not knowingly changed the packet size so I asume it's the default but will check to be sure.

I was wondering if you process the last hop differently to the others such that local issues (pingplotter host issues) could have a greater effect?

Well, I'm so sorry to have wasted your time but I can't seem to reproduce the results I was getting last night so perhaps it was just a fluke.

aplogies all round.
regards,
Ed.

There's not enough of a difference in the processing that you'd expect to see any difference at all - let alone as much as what you saw.



Keep an eye on it and let us know if it reoccurs. It's possible that the latency spike you were seeing didn't exactly match the download period, and that there was some other factor in play.

- Pete

Ok, have been doing some more work on this...

Question:- When I'm downloading a large test file why do unrelated hops further down the chain sometimes show a greater increase in latency than those at the top where you would expect the load to manifest?

Possible answer:- Is it possible that in some circumstances servers can do the opposite of what we normaly expect and return icmp packets faster than they process normal traffic.? If so then this some through traffic latency might not show up at the earlier hops but would still be added to the later ones.???

Just a thought,
Ed.