Im living in a village so my ISP using wi-fi bridge to connect me.
I have this situation always in a day time. At night ping to google is about 60.

http://i.gyazo.com/1a194cc9cc24f91dd93359b0878e7611.png
1 hop - my router
2 hop - ISP's intermediate PC
3-5 hops - ISP

There's always spike on 3th hop, but it's doesnt affect next hop somehow.
Further hops have higher ping, but the last one have not.
In fact I have very high ping.
I guess answer lies in poor bandwidth, but I found it strange that 4 and last hops have good ping in a whole picture.

Hello,

Thanks for writing in!

These are *definitely* some interesting results. Some devices are configured to down prioritize (or not respond to) ICMP echo requests. Usually when this happens, as long as the hop directly after is performing well, then you don't need to factor this behavior into your troubleshooting efforts. We cover this topic in quite a bit more detail here:

http://www.pingman.com/kb/5

Your guess about bandwidth saturation *seems* to be pretty accurate from what we can see in your results. You've got a pattern starting at hop #3 that carries through to your final destination. It is, however, a bit difficult to get a clear picture of this in your data here - as the intermediate hops in your route appear to be down prioritizing ICMP TTL expired packets. The pattern you're seeing at your intermediate hops *looks* to be the same as what you're seeing at your final destination (just amplified as a result of the down prioritization). I've attached a screenshot of what I'm referring to here for reference.

It may be helpful to try tracing to some other targets here - see if you can find something with a shorter route (where the intermediate hops aren't down prioritizing ICMP TTL expired packets). You could also try tracing directly to the device at hop #3 to see what the performance there looks like.

We've also got a guide that goes through some best practices for troubleshooting an issue like this, which may prove helpful to your cause here:

http://www.pingplotter.com/netnirvana/

Hopefully this helps out! If you should find yourself with any other questions, or needing any other assistance - please don't hesitate to let us know.

Best wishes,

-Gary

I thank you for reply.
The problem is correspondence of PingPlotter's picture and real situation: I'm lagging really hard at these moments.
Anyway, can your version about down prioritizing ICMP TTL expired packets can be viable? I mean, somehow on 3rd hop my connection gets down prioritized and I have hard lags.
I tryed to ping directly to 3rd hop - picture is quite same.

Hello,

There's definitely no doubt that you're likely lagging pretty hard - your PingPlotter results *do* show some bandwidth saturation at your final destination.

Hop #3 may simply be down prioritizing ICMP TTL expired packets (which is why when you're tracing to Google, you get a latency spike at hop #3 that doesn't carry on to hop #4). We suggested that you trace directly to the 3rd hop to see if the behavior changed when you were targeting it directly. If the picture looks the same when doing that, then that device may simply be set to down prioritize *all* ICMP requests. The pattern of bandwidth saturation that's affecting your final destination *does* seem to start at hop #3, though (the pattern there just amplified when compared to your final target).

Hop #3 is *most likely* where your issue is beginning. Your goal at this point should be to get a clear picture of this so that you can reach out to the appropriate party (possibly your ISP) to reach a solution. The guide I mentioned in my last post (http://www.pingplotter.com/netnirvana/) has some great tools for building a compelling case to bring to your provider.

If you should find yourself with any other questions, please let us know!

Best wishes,

-Gary