Introduction

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 24.2.82.1. 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.

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.

Conclusions

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.