home page>> Articles Home

Comcast @Home service Uptime Statistics
Continuing information about Comcast internet service reliability

An article by Plainsboro.COM owner Kennedy Lemke
July, 2000; updated October, 2001

What a difference a new cable modem and new splitters makes!

My average monthly Comcast @Home internet connectivity has been 99.9% reliable since July, 2001!

My cable modem connection started becoming unreliable again in June, 2001. Unable to resolve the problem myself, I finally called Comcast customer service and asked them to visit my house to see if they could help me resolve the problem (they had suggested I might need a signal booster/amplifier).

When the cable technician came to my house he determined that I did not need a signal booster, then he replaced two splitters, one inside my house and one just outside where the cable from my house meets the public cable. He also explained to me that the splitters I had been using were "500 MHz" splitters, but that cable modems like to operate at "501 MHz", and that the replacement splitters he installed were rated for "1 GHz"

At the same time, he also replaced the connector on the end of the each cable located outside; I think he installed about 4-5 new connectors all together, completely snipping off the old connector and re-stripping the cable for each newly installed connector.

Around this same time, I began using a new cablemodem that I had purchased from my local Computer City store. This new cablemodem is a "Smart One" cable modem from Best Data, model number CMX110. I think the purchase price was about $200.

Now that a few months have gone by, I've had virtually NO problems with my cablemodem connection to the internet. In fact in the process of installing my new cablemodem, I was moved to a different Comcast subnet and now my upstream bandwidth has increased by about a factor of 4 (used to get about 150Kb upstream, now I average about 600Kb upstream; downstream remains about the same data rate as a T1). NEATO!!!

I'm not sure if it was the new splitters and connectors or the new cablemodem or a combination of both that has caused my reliability to go way up, but needless to say I'm quite happy with this new arrangement and I'm therefore for the time being going to stop updating these reliability statistics pages (though I'll likely still keep performing ping monitoring).

IMPORTANT! If you're having problems with your Comcast @Home internet service's reliability, I suggest you try a similar procedure: have Comcast update the splitters in your home (or buy new 1GHz splitters yourself), and also consider purchasing a new cablemodem. This did the trick for me and I'm hugely happy about it. WAY TO GO COMCAST! THANK YOU!

"With these pages, I hope to inspire and challenge cablemodem and DSL internet providers such as Comcast to make a commitment to [...] reliability." --Kennedy Lemke, July 2000

These pages are about Comcast @Home cablemodem/internet service statistics, specifically for the "ewndsr1" head end located in East Windsor, New Jersey (and serving surrounding communities such as Plainsboro). If you wish, you can click here to skip directly to the stats pages,

Or you can read below for further information about Comcast's cablemodem service and why I decided to begin keeping statistics in June of 2000.



I have been a long-time user and supporter of the Comcast @Home service, and to date I continue to strongly support this service. I have been an @Home customer since August, 1997, and have written several articles on Comcast's cablemodem service (see the links to other articles at the end of this page.

Internet users who have only connected to the internet via a 28.8Kb or 56Kb modem and have never experienced an internet connection via a cablemodem or DSL service at home, or a dedicated internet circuit at work (as many companies maintain), might have a hard time understanding the benefits of such a connection. The combination of always-on internet connectivity and high bandwidth download speed, combined with a reasonable consumer-level rate continues to make these services very attractive. Consumers who have experienced high-bandwidth connections find it impossible to imagine going back to a modem-only connection.

However, one area where the Comcast @Home service seems to be lacking is in reliability. I have struggled over the past several years with an "always-on" internet connection that suddenly stops working and sometimes continues to be down for hours or days at a time. While Comcast hastily agrees to reimburse its customers for such downtime, the reality is that a reimbursement for a day's downtime is not even worth pursuing since the service only costs a little more than a dollar a day.

Cablemodems, DSL service, and other always-on internet services have become ubiquitous in the year 2000, and many of their users (myself at the top of the list) have come to expect the reliability of such services much as we expect our telephones to spout a dial tone when we pick up the receiver (imagine, for example, that your telephone provider routinely has only 90% uptime, meaning that once every 10 times you pick up the phone you don't get a dial tone).

With these pages, I hope to inspire and challenge cablemodem and DSL internet providers such as Comcast to make a commitment to fulfilling this type of reliability.

Why I Started keeping statistics

While I have over the recent years experienced my share of downtime for the Comcast internet service, I have not until recently collected any data on uptime/downtime statistics. I decided in June of 2000 that I should begin doing so for several reasons:

  • If I were to ever complain to Comcast about the downtime I regularly experience, I wanted to have hard data to back up my complaints
  • I consider such a data-collection exercise a good one to perform and share with other consumers who may have experienced similar frustrations with cablemodem downtime
  • I wanted to begin collecting data to offer Comcast an opportunity to show that their cablemodem service's reliability is improving over time.

What data is collected and how it is done

I have tried to keep the data that I collect as simple as possible; in my opinion, simple data is easier to convey and understand. Thus the data I chose to keep is the simplest possible: "Is my cablemodem internet connection up or down?"

In keeping with the simplicity theme, the method I have chosen to identify whether the service is up or down is also simple: I use one of my home UNIX (Sun Microsystems) machines to regularly run a version of the "ping" command. The ping command is among the simplest of IP services in that it simply sends a request over a network to a particular machine or set of machines and waits for the remote machine(s) to respond to the ping request with "yes, I'm alive". If the ping request is successful, I record this in a log file. If the ping request fails after some short amount of time (about 5 seconds), then I record a failure.

At the same time, I did not want the amount of traffic generated by my pings to be a burden on the available network bandwidth, and I have thus chosen to execute the ping command only once every 5 minutes (288 times per day), regularly executed out of the unix cron facility.

Finally, the question remains: "To which remote host should we direct the ping?" In keeping with the simplicity theme, I have chosen to use the host that is the default gateway for the "ewndsr1" head end. I believe this host is very likely some sort of simple router; in the case of "ewndsr1", the IP address of this default gateway router is Thus, every 5 minutes, my unix machine executes a ping request to this IP address and record the results. I use the IP address itself as an argument to the ping command instead of using a host name; doing so eliminates the possibility that an unsuccessful ping might be the result of a DNS problem rather than a network problem.

Using the default gateway as a ping destination makes the most sense. This is the machine that is, from a network standpoint, the "closest" to the source machine. For IT departments in environments where internet uptime is required at all times, you should expect that (aside from scheduled periods of maintenance) the default gateway machine should be respond to a ping request very close to 100% of the time. In fact, anything less than 100% uptime is probably indicative of a serious problem, much as not hearing a dial tone on your telephone would be indicative of a serious problem with the public telephone network and/or your local telephone service provider. Similarly, it should be the goal of any cablemodem provider to provide similar uptime reliability for its customers.

I could have chosen any one of the 10's of millions of internet-accessible hosts as a remote ping destination, but I felt that doing so would not be apropos: since my goal is to determine Comcast's level of cablemodem system reliability, using a more remote host would introduce too many variables (i.e., too many internet "hops"), most of which Comcast has no control over.

Data collection summary: the data collection that I do, then, is essentially the same thing a picking up your telephone every 5 minutes, determining whether or not you have a dialtone, and recording the results ("yes" or "no").

Why downtime occurs

So, we know that I have picked a fairly simple design for my test of reliability for the Comcast @Home cablemodem network. But it is worthwhile to list/discuss what types of conditions result in a successful ping versus those conditions result in unsuccessful pings.

Here is a list of possible reasons why a ping from my unix machine to Comcast's head end router might be unsuccessful:

  • My unix machine might be experiencing some difficulty that would prevent a successful ping. This might be because the cron facility has crashed, an ethernet cable has become unplugged, or that machine itself it down. For the most part I dismiss this as a possibility, since my unix machine has been quite reliable for several years, and is running a reliable operating system (Solaris 7). Most likely if the unix machine were to fail, there would simply not be any log entry for a particular time slot.
  • My prestige 310 cablemodem router could be down or malfunctioning (I currently do not connect my unix machine directly to the Motorola cablemodem that I am renting from Comcast; rather, I have inserted a cablemodem router into the loop which allows me to have a local, secure home network consisting of multiple machine that all share the cablemodem connection). While I have experienced a few intermittent problems with this machine (mostly "network slowness"), I am aware of no malfunctions to date have resulted in an unsuccessful ping from my unix machine to Comcast's "ewndsr1" head-end router.
  • There could be a problem with the cable connection that plugs into the cablemodem. I tend to dismiss this as highly unlikely since the cablemodem does tend to perform perfectly for days at a time. If there were a problem such as RF interference due to an improper connection or other cable problems due to splitters that are in my home, I would expect far more frequent problems, and few occasions of continuous uptime.
  • There could be a problem with the Motorola cablemodem itself that I am renting from Comcast. The model cablemodem that I have been given to use by Comcast is a fairly simple model from a user standpoint. You plug in power, your cable connection, and an ethernet cable. There are three corresponding green dummy LED's on the front of the cablemodem and a fourth amber LED that indicates a power-on test. Invariably, if I note a failed ping from my unix machine to the head-end router, and check the dummy lights on the cablemodem, I see that the power and ethernet lights are on steady (no problem indicated), but the light for "cable" is blinking (indicating a problem). Occasionally when the cablemodem is in this state I cycle the power on the cablemodem by unplugging it (there is no on/off switch) for 15-30 seconds then I plug it back in again. After a brief test period the cable light may come back on steady green. However, more often than not, cycling the power on the cable modem does NOT solve this problem--that is, after the test period, the "cable" LED continues to blink indicating a continuing problem: that the cablemodem is unable to communicate with the head-end hardware.
  • There could be a problem with the cable network between my home and the Comcast head end. I am not familiar with precisely what equipment exists between my home and the location of the head-end router, other than to say there are likely a number of repeaters and other equipment that are used to broadcast and boost signals from one cable segment to other cable segments. In my (admittedly layman) opinion, this is the most likely cause of any outage whether it is short or long; there is some cable or cable repeater between my home and the Comcast head end that is malfunctioning or receiving interference, etc. that is causing my cablemodem to be unable to communicate with the head-end router.
  • There could be a problem with the head-end router itself. Such a problem could be with the hardware itself, or a routing issue, or a loose or disconnected cable at the head end location. While I do not know exactly what equipment is used for cablemodem head-end routers, my experience with routing equipment to date tells me that in general, routing equipment is quite reliable and is unlikely to be the cause itself of a failed ping
  • I might not be using reasonable parameters for the ping command. I think I am, however.
  • A thunderstorm or other act of man or God has interrupted service. I have noticed that if a thunderstorm is in the area, there seems to be a fair chance that I'll lose connectivity for some period of time. Also, other bad weather or some man-made problem like a backhoe cutting a cable might be responsible some of the time for interruptions in service.


In my estimation, the most likely cause of an unsuccessful ping from my unix machine to the cable company's head-end router is likely to be a failure in a cable or equipment between my home and the cable company's head end. The second most likely possibility would be an act of God (weather) or an accidental act of man (cable cut, for example) that would cause a problem.

It should be noted here that an unsuccessful ping from my unix machine to Comcast's head-end router does not necessarily indicate that Comcast is experiencing a downtime problem, and similarly, a successful ping does not necessarily indicate a positive result for internet connectivity. In fact, in early July 2000, I experienced a period of about 4 hours one morning where my unix machine was able to ping the head-end router successfully (and in fact I was able to ping other client machines on the same subnet), but I was unable to connect to any IP host on the internet-side of the head-end router, and I was unable to use the traceroute command beyond the default gateway. In this case, the data will show the cablemodem internet service as being "up" when in fact internet access was not possible during this time period.


Please feel free now to continue on to the statistics page.

Links to other Articles

I have used and studied cablemodem internet connectivity based on my own experiences quite a bit over the past several years. Here are some links to other articles I have written about cablemodems that may interest you: