Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : America On-Line (AOL) -- Ignore unavailable to you. Want to Upgrade?

To: Tecinvestor who wrote (29637)	8/19/1999 11:56:00 PM
From: stewart kagel	Read Replies (2) \| Respond to of 41369

The boston globe did a side by side study of cable vs. dsl. Here is the url: boston.com I believe the article expires tomorrow. I am not sure I buy the info as suggested by the author. My experience with DSL is more positive than suggested by the article. Bell Atlantic did come to my house to split the lines. It took all of 10 minutes. My understanding is that soon they will not be required to make that trip. The technology is advancing that rapidly. AOL was wise to hook up with DSL. Second to the dance (behind cable) doesn't mean it has no value. It just seems that many of the pundits are fixated on cable. My guess is that AOL will eventually have a cable deal. I just am tired of reading that it is either cable or nothing.

To: Tecinvestor who wrote (29637)	8/20/1999 7:50:00 AM
From: Frank A. Coluccio	Respond to of 41369

Re: " I was trying to get a feel as to whether DSL degrades more or less than cable modem under taxing circumstances. I still do not have the answer to that." From an access standpoint, the degradation you are speaking of could potentially take place on the loop (front end), or the central office DSL Access Mux, or the back end feed towards the larger cloud. [[Of course, other areas could be your own terminal gear (PC, whatever), the core of the Internet, or the targeted servers you are going to. But your question has to do with loop access contention, so we'll limit our focus to that topology.]] Since most RBOC DSL offerings employ ATM backplane fabrics in their DSLAMs, the congestion is not likely to be found on the loops themselves, or the DSLAM, rather, congestion would take place in the back end uplinks to the cloud if they weren't robust enough to withstand an onslaught from high user activity on the loops. The limitation, in this case, is not one that is endemic to the technology, rather, it is caused by improperly sizing the T1/T3/OC-n capacity towards the greater Internet. Having said that, I should also point out that there are DSL variants called DSL Access Concentrators (DSLACs) that do not use a Layer 1/2 switching fabric like those used by the RBOCs. Instead, they use contention-based Ethernet-like frame backbplanes which could result in congestion and increased latency in other areas of the topology, such as in the loops themselves (resulting from back pressure from the DSL concentrators), or the concentrators themselves. However, it is unlikely that you will see these forms of DSL being employed by the larger ILECs. DSLACs tend to be favored by startup ISPs and a number of smaller Data LECs, and possibly by organizations who will use them for MDUs or for proprietary uses in campuses, due to their lower price points, effectively presenting a reduced barrier to entry. In the greater number Cable HFC systems, on the other hand, present congestion in the last mile, when user activity increases, is due to a fixed and limited channel capacity between the head end and the cable modem (in addition to the other variables I've mentioned above) which must be divided by the number of users who are online at any one time. Most HFC systems (CMTO being an exception when ATM is invoked in their gear) follow a similar set of dynamics as those in the DSL contention model (based DSLACs) which I mentioned above. Improvements are being made in some areas to increase the last mile bandwidth in cable systems by radically reducing the number of users per segment from hundreds or thousands per segment to only <75 per segment (witness the work being done by T in SLC), but these are still in trialing stages right now in many ways, and will not become pervasive for some time to come.