dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed


reply to odog

Re: [AZ] Huge latency and packet loss issues in the Valley Area

I am actually trying to track down a "consistency of service" issue with Cox (Scottsdale AZ) but thought I would post what I just got on a tracert to the ip in this thread. Done at 4:35pm.

It appears Cogent has been replaced by XO

Tracing route to over a maximum of 30 hops

1 1 ms 1 ms 1 ms
2 18 ms 8 ms 9 ms
3 9 ms 10 ms 9 ms
4 11 ms 20 ms 13 ms
5 10 ms 9 ms 11 ms
6 23 ms 21 ms 23 ms
7 22 ms 21 ms 22 ms []
8 20 ms 31 ms 21 ms []
9 23 ms 29 ms 22 ms []
10 78 ms 80 ms 78 ms cr2.la2ca.ip.att.net []
11 79 ms 79 ms 80 ms cr1.slkut.ip.att.net []
12 91 ms 94 ms 91 ms cr2.dvmco.ip.att.net []
13 83 ms 83 ms 82 ms cr1.cgcil.ip.att.net []
14 78 ms 77 ms 76 ms gar2.clboh.ip.att.net []
15 79 ms 80 ms 89 ms
16 79 ms 79 ms 79 ms
17 * * * Request timed out.
18 * * * Request timed out.
19 ^C

I will check other threads here to help figure out why I get a lot of drop outs with my Preferred service. If I go to 8x8.com and do their VOIP test I get very low consistency results (27%) and speed of 25down/1.9 up It was not this way just a few months ago. Even though Preferred is supposed to be 15/2 a speed test with cox shows 32/22. Speedtest.net (to Brinkster) is 32/12. It seems that consistency of service (quality of service) has a big impact on any type of streaming including voip or some gaming.

Has anyone tried using »www.8x8.com/Resources/Tools/VoIP ··· est.aspx to judge the quality of their connection?


Phoenix, AZ
They must have crappy servers or something.. I got 30mbps down and 25 up.. On speedtest.net I got 120/30..


I'm getting ~60% packet loss through A sample mtr output to "google.com" is available here: »dpaste.com/hold/920123/


Phoenix, AZ

1 recommendation

it's been posted several times, cox's routers will de-prioritize or even drop icmp. If you're not seeing packet loss after that hop, there is nothing wrong.

I gave her time to steal my mind away
San Jose, CA
·Pacific Bell - SBC
reply to bps
I concur with nickphx See Profile. The truth is, every diagnostic trace packet is dropped by every router on a route. When they do return a response, it is a different packet from the one you sent; which requires extra processing time for the router. So they don't always take the time to respond.
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum


Mesa, AZ
·Sprint Mobile Br..
·Cox HSI
Traceroute is just a standard ICMP echo (aka ping command) only we start the TTL in the IP header at just 1, and then increment it each time to find successive hops.

For those who don't know, the TTL is a value that decreased by one each time it passes through a router (aka a hop). When the value reaches zero, the router where it hit zero will send a return packet indicating that the TTL expired in transit, which includes its own IP address. This is done to mitigate downtime caused by routing loops. A side effect is that it allows traceroute to identify all of the hops between you and the destination (otherwise routers are invisible.)

Many routers are configured to ignore ICMP echo requests however, so when one lands at their interface with an expired TTL they just discard the packet and don't return a notice that it was discarded. This is typically done for security reasons rather than performance reasons. If your destination host also ignores ICMP echo, (All versions of Windows Server that I have used are configured to do this by default, by the way) you'll never know exactly how many hops it takes to get to your destination, so traceroute will just keep counting up until it reaches the max number of hops you specify (windows defaults to 30 IIRC).