I've been using PingPlotter for several months -- WORKS GREAT -- it get's my ISP to listen to me. (They use it too)

Lately I've seen something for which I can'f quite figure out the cause, and am hoping someone on this fourm might have an idea.

Setup: two different LAN'd computers (Window 98 and XP Pro) pinging through -- in order -- a linksys router, linksys switch, linksys cable modem into Cox Northern Virginia's high speed internet. (My modem is provisioned by the ISP for 192K up, and 3MB down -- and I almost always attain these speeds on various internet speeds test sites)

To monitor my ISP, I'm pinging my primary DNS -- five hops.

With PingPlotter's ping interval set to 50 ms, all five hops are SOLID.

However, when I decrease the ping inteval below 50ms, I begin to experience significant packet loss on hops 2 through 5 (i.e. the hops AFTER the first ISP router). Hop #1; from my house to the 1st ISP router remains solid.

If I decrease the ping interval down to the 25ms PingPlotter default, I get 30-50% packet loss on each of the last 4 hops, while hop #1 to the 1st ISP router remains solid.

It's almost as if the first ISP router can't handle the sucessive hop pings if they come any faster than 50ms apart.

Any Ideas ... ???

Stumped in Virginia

I should have added I received the same results when -- for testing -- I bypassed my entire LAN and connected the PingPlotting computer directly to the cable modem.

This happens usually when a router in the chain doesn't know how to deal with multiple outstanding ICMP echo requests - usually the router closest to you (ie: your cable modem in this case, but possibly another). This is almost always a deficiency in a router that is often solvable by updating the bios in the router, or changing a setting.

The problem is seen as you decrease the time interval between hop traces because as you do so, you increase the likelyhood of overlapping outstanding packets - especially at the point where your latency exceeds the interval between hop traces (hop 1 might be responding in < 10 ms, so it won't show packet loss, but further down it might be 35, or 80, or 200ms - so there will almost certainly be multiple outstanding requests there).

You'll probably get much worse packet loss as you trace to a host that has higher latency. This is an artifact of the router, not a problem with your computer, with PingPlotter, or with any of the routers showing packet loss.

You can change the settings in PingPlotter so that your router behaves more like you want it to, though, and changing the way simultaneous packets are sent.

Several years ago, the Netgear RT314 router had a similar problem (now corrected) - and we have a page on how to configure for *that* problem that should also address your problem today:

http://www.pingplotter.com/netgear-rt314.html

If changing these settings doesn't correct the problem, then post back here and we'll work on some other solutions. If it *does* correct the problem (almost certainly it will), we can help you determine which router is causing the problem (ie: cable modem or something inside your cable complex).

Pete

Intesting, thanks.

That certainly explains what I'm seeing.

I've effectively done the same thing by slowing my ping interval. (The return echos come back in the 9-15 ms range so I don't have any "outstanding" pings before the next one is sent 50ms later.

Question: If I "remove" my router from the equation completely, and connect directly to my cable modem, wouldn't that mean that the 1st ISP router is the one having the problem as pings to it come back "good" while it's the ones to "later hops" which seem to get "lost"

The only problem with this is that if you get a timeout, then you'll have multiple outstanding requests that could influence other hops. This might make a single lost packet cascade several other lost packets around it that isn't real. This depends on how the router in question is behaving, though.



It could also be your cable modem itself. The 1st hop might be the one causing it, but the first hop might report back in a more timely fashion - so there are never any outstanding requests when the first packet gets sent out. This is pretty normal - as hop 1 is *always* sent out first, and the problem in the "router" might be that the first packet works fine but other ones do not.

One way to test this is to crank up the trace interval to something insane (with the caveat that you might flood some poor router someplace and give it a heart attack or similar, so please be careful in your use of aggressive trace intervals). You can set your trace interval (from the main screen in PingPlotter) to as low as .01 seconds (or 10ms). The timer resolution in Windows isn't high enough to get anything less than 10ms, but using .01seconds might cause some overlapping packets at hop 1 that might show that the problem actually occurs before hop 1 (ie: your cable modem). If hop 1 normally responds within 10ms, this method should still work since hop 2 will be outstanding from the previous set before hop 1 of the next set goes out. Fun stuff, eh? I would suggest trying something like this (although keep it as short in time as possible - as 100 pings a second can cause some problems) to see if you can isolate which router (hardware device in general) is causing the problem.