Thanks guys
> Traceroute is not the proper tool to ascertain the bandwidth
available.
Chuck, I am not using traceroute to determine bandwidth Just using that at selected times because it shows all the hops to the designted IP in milliseconds, which often reveals a big delay in one of the hops. Have to show the ISP that the bottleneck is in their stations and not farther out in the internet.
> Even traceroute packet loss doesn't
necessarily indicate a problem, since the lower priority of the ICMP
or UDP traceroute packets means they might get dropped intentionally
if the router is busy processing real traffic.
Where is this lower priority determined?
> If the ISP is asking you for a traceroute...
ISP is not asking me for a traceroute. ISP is asking me to prove how poorly their 20 mb/s internet (which I am testing) "works." They want me to buy this service permanently at a $25 increase over my usual rate for the 10 Mb/s service I usually subscribe to --which isn't usually anywhere near 10 Mb/s either. Meanwhile, I want them to fix the poor-bandwidth problem we've had here for 4 1/2 years. Also meanwhile, during the times of worst bandwidth here, I find very-long latency times in the ISP's closest hops here. For whatever reason these are happening, I think they should see that.
What I am doing is trying to assemble as many tools with as much info as possible, in order to communicate this problem to them.
> If you really want to test the performance of your connection, you
need two well-defined endpoints, such as your PC and a server at your
ISP, both running software designed for this purpose.
I am also using the server at the ISP which they recommended, using a little gui they have for this purpose. Typical bandwidth today between 12 PM and 2 PM was running between 9 Mb/s and 14 Mb/s, on the service that's supposed to give me 20 Mb/s.
Thanks for the other recommendations & ideas, I will check them out & read the recommended pages.
Liz J