SI
SI
discoversearch

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 : Frank Coluccio Technology Forum - ASAP

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Frank A. Coluccio who wrote (151)10/31/1999 10:15:00 PM
From: wonk  Read Replies (1) of 1782
 
Frank:

In regards to over-the air broadcast transmission standards, I was probably just shouting into the wind.

I do find your question to Dave about the all digital cable distribution plant interesting because it brings back to the forefront of my mind the discussion that was started well nigh over a year ago - Silkroad.

If I can quote this section of Dave's post in its entirety:

...HDTV has to “catch on” first, since that has far and away the maximum Bandwidth Sucking Power of any applications available today. Average bandwidth demand per user probably needs to increase 500% or more.

Since a TDM stream that aggregates all the channels across, say, a gigahertz of bandwidth makes for a much more expensive receiver (today) than one that merely has to deal with under 40Mbps encoded within a 6 MHz channel, cost is also an issue. The FDM channelization currently used (i.e. the 6 MHz channels used today, whether they contain a single analog NTSC TV channel or multiple digital channels), also makes for much easier planning and re-arranging of multiple services besides the basic push-channels of video only, as well as mixing and grouping service offerings in their own spectrum chunk.

When such all-digital systems do get addressed, and assuming for the moment that DWDM will persist and capacity will get even higher, the FDM model of the old system could cross over to the new system. Maybe even to the point that an old 6 MHz channel maps to a single lambda, thus expanding the capacity of a 6 MHz channel easily by an order of magnitude....
#reply-11759339

While Silkroad still is an unknown quantity, if it turns out to be the "breakthrough" any where near as claimed, I believe it will the facilitator of the all fiber, all digital, universal mechanism for video distribution. My belief rests on two of its claimed characteristics: (1) massive capacity and (2) ease of add/drop.

While one could argue that the stake through the heart that killed Tele-TV was the Telecom Act, I have heard from a number of people formerly inside that there was already a diminishing of enthusiasm for the project due to the inability to provide true video on demand. All the various flavors of FTTN and FTTC couldn't satisfy the bandwidth requirements of a system which was expected to achieve penetration parity with the incumbent cable operator, when one factored in the bandwidth requirement for true VOD. VOD and even NVOD was one of the primary pillars of the business plan to achieve that penetration parity - the technology just couldn't do it, and generate any kind of ROI. HD content just makes it worse.

Perhaps I'm way out of my league, but my impression of DWDM, while impressive technologically, is that it is kludge. It's my understanding that it works economically as a bandwidth multiplier on long haul routes, due to the limited (in the abstract) number of on/off ramps. My intuitive sense, without crunching any numbers, is that multiplying the offramps by the number of subscribing HHs in a metropolitan cable system is cost prohibitive, and will remain cost prohibitive even given rapid price declines and performance increases - due to the average consumer's bill tolerance for video services.

But Silkroad, if the claims be true, has the capacity to do VOD. Furthermore, the add/drop (again if the claims be true) is cost efficient.

just my two cents,

ww
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext