ISP recommendations in the Overland Park KS area 66210 [x-adr ][x-sls]

[Gerald Combs]

Garrett Goebel wrote:

> Jonathan Hutchins wrote:
>> On Friday, May 21, 2004 01:30 pm, Michael wrote:
>>
>> > I am looking for recommendations of who is good and bad as an ISP.
>> > I am looking for a Static IP (one or two) - best would be 6 routable
>> > addresses.
>>  
>> What kind of bandwidth are you looking for?  Cable modem is the best
>> for the buck, a commercial account should give you what you need.
> 
> YMMV: DSL usually has lower latencies...
> 
> http://jamesthornton.com/writing/cable-vs-dsl-latency.html

Given the data:

DSL: adsl-68-92-149-68.dsl.austtx.swbell.net
--- 68.92.149.68 ping statistics ---
333 packets transmitted, 333 packets received, 0% packet loss
round-trip min/avg/max/mdev = 20.570/22.597/41.045/1.423 ms

Cable: cs666838-214.austin.rr.com
--- 66.68.38.214 ping statistics ---
333 packets transmitted, 333 packets received, 0% packet loss
round-trip min/avg/max/mdev = 69.617/80.451/120.461/12.282 ms

I disagree with his conclusion:

  "The inconsistent times are expected with the cable network party-line

   architecture. With cable, everyone in your area uses the same large
   connection so if many people in your area are online at the same
   time, it will be more congested. I ran this test at 1:30 p.m. when
   most people are at work and not using their cable modem so it's a
   good bet that the latency and inconsistency will be much worse in the
   evening."

While this certainly shows that austin.rr.com has plenty of lag, it
doesn't indicate congestion.  When networks are congested, routers and
switches tend to throw away lower-priority traffic.  This means ICMP
most of the time.  Zero out of 333 pings were lost, so it doesn't look
like either service was congested.

Since he didn't run any traceroutes it's up to us to guess where the lag
is actually happening.  It could have been somewhere on austin.rr.com's
network, or at some point beyond.  It could have been due to slow
equipment on his end.  We'll never know.

BTW, the "network party-line architecture" thing is a myth.  Google
turned up a pretty good explanation (item five):

http://www.techtv.com/callforhelp/features/story/0,24330,3313660,00.html

Let's try from my cable connection at home.  Sending 500 pings gives me
this:

500 packets transmitted, 499 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 38.994/76.823/445.387/69.498 ms

My ping times are on par with his, but with a larger variance.  When I
traceroute out, I see this:

 1  10.63.128.1  6.294 ms  11.336 ms  7.581 ms
 2  24.31.239.65  8.770 ms  6.945 ms  8.139 ms
 3  24.94.160.194  6.689 ms  7.457 ms  7.63 ms
 4  24.94.160.1  9.146 ms  8.497 ms  7.580 ms
 5  66.185.142.25  7.761 ms  8.358 ms  17.566 ms
 6  66.185.137.226  9.26 ms  9.413 ms  9.554 ms
 7  66.185.152.128  27.559 ms  21.544 ms  25.545 ms
 8  66.185.133.99  27.790 ms  20.882 ms  30.751 ms
 9  204.255.173.37  25.774 ms  19.999 ms  38.17 ms
10  152.63.97.61  21.300 ms  26.975 ms  19.544 ms
11  152.63.2.181  19.725 ms  18.992 ms  19.529 ms
12  152.63.1.150  36.800 ms  37.488 ms  39.82 ms
13  152.63.88.246  38.375 ms  37.516 ms  37.476 ms
14  152.63.90.105  49.348 ms  37.998 ms  40.75 ms

The first 4 hops aren't fantastic, but they aren't terrible either.
Significant latency shows between hops 6 and 7.  Those addresses
belong to ATDN (the AOL Transit Data Network, which apparently provides
peering for kc.rr.com).

So my latency exists because kc.rr.com has a crappy peering partner, not
becuase cable is somehow worse than DSL.  I'd be willing to bet the case
is the same for austin.rr.com.