[ale] OT: Comcast'ers

Jim Popovitch jimpop at yahoo.com
Mon May 29 00:41:20 EDT 2006


OK, an update....

First, thank you to Daniel (comcast user and RF engineer),  Robert (RF 
guru) and Brian (a Comcast "in-the-know" employee).  All three of you 
exemplify expert people willing to help others.  Thank you.

My recent cable modem problems have been alleviated by upgrading my 
modem and changing the RF line to a piece of quad shield RG-6.  I no 
longer seem to experience the de-registrations and drop-outs that I was 
experiencing 4 or 5 times a day.  Why did this suddenly appear?  Well, 
shortly before leaving for vacation last week I moved a stereo unit next 
to where the cable modem is.  Along with the stereo unit came a power 
distribution block that everything plugs into.  It just so happens that 
the old RG-59 for the old modem ran right next to the power cords. 
Replacing that RF cable with the quad shielded RG-6, and putting some 
space between the power cords and the cable, helped limit noise on the 
line. I have tested this with my old cable modem and it seems to work as 
well as it did before.  The old modem's bios isn't up to date, and the 
newer modem has a better signal-to-noise ratio, so I am keeping the new one.

The "packet loss" seen from my mt tests still exists.  BUT this is 
natural and normal based on discussions with Brian.  Here is Brian's 
good explanation:

   ..the "mtr" application is sending packets with various TTL values
   (1, 2,..., n).   The TTL value is decremented by one each time the
   packet pass through a router.  When a router receives a packet with
   a TTL=1, it can send an ICMP TTL time exceed packet to the device
   which src'd the packet.   The "mtr" application expects to see one
   of these ICMP TTL time exceed packets for each packet it sends. When
   it doesn't, it reports the lack of a response as a "packet loss".

   What's happening is that D1stonemtn router is not sending a ICMP
   TTL time exceeded packet back to the src for each TTL=1 packet
   received. This doesn't mean there's packet loss in the network,
   but instead that the router is not responding to each TTL=1 packet.

   Here's a way to confirm this.  Pick some IP, and run the "mtr" app
   to this IP while at the same time perform a per second ping.   I
   expect you'll see no packet loss in the ping but "mtr" might report
   "packet loss" on some of the Comcast hops.

Comcast is rock solid once again, and I am getting 6MB down and 384Kbs 
up. (fully tested and verified, of course)  :-)

-Jim P.


Jim Popovitch wrote:
> Open up a terminal session and mtr to www.test.com.   Notice any 
> significant packetloss inside of Comcast's Atlanta headend?
> 
> I consistently see ~15% loss at 
> 10g-9-3-ur01.B0atlanta.ga.atlanta.comcast.net.  Anyone else?
> 
> -Jim P.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
> 



More information about the Ale mailing list