asv@gaboon.UUCP (Stan Voket) (09/30/90)
Some time ago I read that cable TV companies will sometimes sell/rent surplus bandwidth on their lines for computer networking. I'd like to learn more about the concept and mechanics behind this. How does this work? Thanks in advance! :-) -- +----------------------------------------------------------------------+ | - Stan Voket, asv@gaboon - OR - ...uunet!hsi!stpstn!gaboon!asv - | | - Voice: (203) 746-4489 - FAX 746-9761 TELEX 4996516 - | +----------------------------------------------------------------------+
combstm@stat.appstate.edu (09/30/90)
In article <6722@gaboon.UUCP>, asv@gaboon.UUCP (Stan Voket) writes: > Some time ago I read that cable TV companies will sometimes sell/rent > surplus bandwidth on their lines for computer networking. I'd like to > learn more about the concept and mechanics behind this. > > How does this work? > We have expermiented with the local cablevision group in town to try to run data over the cablevision broadband. Our University also has all of its buildings cabled on a mid-split broadband coax system, so we have lots of experience in this. It does not work well with cablevision. The cable must be tuned almost to perfection, with the db levels set properly to have a perfect signal. Snow on tv reception does not hurt the viewer appreciably, but "snow" on a data cable spells error recovery and corrupted data. We have installed point-to-point lines and avoid the cablevision route. - Terry Bitnet: COMBSTM@APPSTATE Internet: COMBSTM@Conrad.Appstate.Edu
jim@syteke.be (Jim Sanchez) (10/22/90)
I would take STRONG exception to the the proposition that a CATV
system must be tuned to perfection to be used as a network medium.
Since my company (formerly Sytek) started out in the broadband (CATV)
networking business and have by far the largest installed base on this
medium, I think I can comment. The biggest issue that you need to be
aware of is how many bits/sec do you want/need to squeeze into each
MHz of cable bandwith. The higher that number, the smaller the
dynamic range of your system and the smaller the tolerance on the
signal level. For example, 802.4 token buss (which IS if I remember
right what Appalacian State uses) crams 10 Mb into 12 Mhz and does not
like much variation in RF levels. If, on the other hand, you use the
IBM Broadband PC network it puts 2 Mb into 6 MHz and has more than
twice the dynamic of the 802.4. No mysteries here just plain old
engineering - there ain't no free lunch here either.
Cheers
--
Jim Sanchez | jim@syteke.be (PREFERRED)
Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim
Brussels Belgium | OR {sun,hplabs}!sytek!syteke!jim
--
Jim Sanchez | jim@syteke.be (PREFERRED)
Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim
Brussels Belgium | OR {sun,hplabs}!sytek!syteke!jimhaas%basset.utah.edu@cs.utah.edu (Walt Haas) (10/23/90)
In article <1649@syteke.be> jim@syteke.be (Jim Sanchez) writes: >I would take STRONG exception to the the proposition that a CATV >system must be tuned to perfection to be used as a network medium. >Since my company (formerly Sytek) started out in the broadband (CATV) >networking business and have by far the largest installed base on this >medium, I think I can comment... Well since we are satisfied users of the Hughes 8200 (formerly Sytek) token bus bridges to connect Ethernet over broadband, maybe our experience would be useful to somebody. We had an old cable TV system which we upgraded to a 450 MHz high-split system for the purpose of running data. We do in fact successfully bridge our campus Ethernets today over this system, and it works pretty well. The main thing we had to do is drastically raise the engineering standards used by the TV guys. When I took over this system it ran TV just fine, and ran data well enough for people to try to rely on. Unfortunately it did not run data well enough for users to be satisfied. There were two main reasons for this: 1) TV can tolerate large errors in system tuning. The reason is that TV signals are on constantly, whereas data signals using most modulation schemes (such as the 802.4 used by the HLS 8200) have many devices on one channel that share the channel by turning their carriers on and off. TV receivers have Automatic Gain Control which is good at adjusting input levels to compensate for alignment errors. AGC is impossible when signals are turned on and off every few microseconds. 2) TV is generally immune to ingress. Our HLS 8200s are run at the factory default frequency, so the top half of their range falls on the lower half of the FM band. If we pick up a strong enough FM signal on our reverse channel it will render the 8200s unable to communicate. When I took over the broadband, it had large alignment errors and ingress problems. The only data application which worked reliably was some point- to-point RF modems which did not rely on switching carriers on and off, and which therefore were able to make effective use of AGC. These modems also were on a frequency which did not experience significant ingress. We now have a system with no alignment errors of more than 2 or 3 dB, and ingress at least 25 dB below nominal reverse channels. It took a lot of work to get to this point, but we were rewarded with a drastic improvement in data reliability. If you have to live with a TV system, one approach you might want to take is to do the following: 1) Closely investigate the ingress situation. See if there are some free reverse channels that don't suffer ingress. 2) If there are alignment errors, get some point-to-point RF modems that have effective AGC and use them instead of a technique that switches the carrier on and off. The other thing that limits the reliability of a broadband system is, of course, the large number of active electronic components that need to be working in order to get from point A to point B on the system. It is pretty standard for a typical path on our system to involve 15 or 20 active components. We will be moving to fiber optic over the next several years for both increased reliability and increased bandwidth. That isn't to say anything bad about our HLS 8200s, which work fine; if you want to understand the reliability issue you just need to count boxes - and think about ingress. -- Walt Haas haas@ski.utah.edu