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.