![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Kelly Brown wrote: > The problem with cable is that you share the cable to the concentrator. As > more folks subscribe in your neighborhood, and during peak times (esp. with > pay-per-view) the available bandwidth to you will drop. That's not where the problem is; there is far more capacity on each segment than required. The problem with my own cable-modem service is the lack of monitoring. By contrast to ISP companies which built themselves from the ground up with monitoring capability on every 24x7 circuit, the cable companies seem to basically have no idea where the bottlenecks in their networks are. AT&T developed a specification which is actually fairly sound. A cable segment "passes" 420 households, delivering 40 megabits of capacity in the downstream direction. I've forgotten what the upstream capacity is, but it's also fairly high. It's *not* like an Ethernet; the upstream and downstream channels are on different channels entirely. Allocation of bandwidth across subscribers works more like a token ring than an Ethernet, but it's a whole new design. Look for 'docsis' on your local search engine to read more about this. Hence if every one of your neighbors were: (a) subscribing to the cable- modem service, and (b) downloading from the net simultaneously, you would still be getting about 100 kilobits of downstream capacity. Chances are, the entire cable connection to your town is a single 45-megabit DS3 connection or (even more likely at this stage of the game) a handful of 1.5-megabit T1's. At the head end beyond the cable concentrator, it's the usual set of Cisco routers and so forth that any ISP uses. So the choke point is really at that point, not in your neighborhood. Service quality depends--like any ISP--on how well the company monitors traffic on the various segments and on how well it provides fault tolerant connectivity to handle the traffic. -rich - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |