Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!bu-cs!kwe From: kwe@bu-cs.UUCP Newsgroups: comp.dcom.lans Subject: Re: BASEBAND vs BROADBAND Message-ID: <4850@bu-cs.BU.EDU> Date: Tue, 3-Mar-87 15:12:26 EST Article-I.D.: bu-cs.4850 Posted: Tue Mar 3 15:12:26 1987 Date-Received: Thu, 5-Mar-87 21:56:07 EST References: <1148@ssc-vax.UUCP> Reply-To: kwe@buit13.UUCP (Kent England) Organization: Boston Univ. Info. Tech. Lines: 74 Keywords: baseband broadband Just some notes on the very fine discussion of baseband vs broadband. In response to a comment by Phil Ngai on the unreliability of broadband components, it has been my experience that broadband modems, amplifiers, headends, etc are no different than any other electronic equipment. Mature products tend to be very reliable. Many LAN cable plant equipment vendors (Sci Atlanta, C-Cor, etc) sell pilot tone generators for amp AGC circuits, redundant amp circuits, and status monitoring equipment. This kind of thing lets net managers sleep better but I don't think that a well-designed and maintained system benefits much from these extras. In response to Anders Andersson's thoughts on using broadband for terminals, it sounds like he is thinking of using point-to-point modems. Please don't! My experience with point-to-point RF modems has been very poor compared to using a broadband LAN (Ungermann-Bass terminal servers, to be precise). We thought that we would save bandwidth on our 5Mbps broadband LAN by putting heavy use point-to-point channels on separate sub-channels. A bad idea, in hindsight. These things need to be tuned when installed and they use fringe channels that are difficult to keep in spec. There is no LAN software to handle the inevitable idiosyncracies of point-to-point equipment that was never designed to have anything other than a hard-wire between. A software-based LAN (broadband or baseband) is far superior to point-to-point subchannels. In response to Jim Bigelow at Tektronics who had problems expanding his broadband and didn't want to hire specialized RF techs, I would say that good design is more important than super-techs, although a really good tech like mine is worth his weight in gold. Good design requires building expansion into the design at the start. This means laying out all trunk runs between buildings at the start, even if some will not be installed initially, and designing in the amps where needed to support future legs. The problem is that most vendors still design broadband networks to minimize components and not to maximize expansion flexibility. I imagine this to be a carry-over from cable TV. Most designers, like Allied Data, do their design with computer systems that use the minimum component algorithms. Using these programs you don't have a prayer of getting a system that is expandable. How do you get a good design? I have two people on staff, and engineer and a tech, that both understand good design and good maintenance. This is the main reason that BU's broadband system has gained a reputation on campus as being very reliable. If you are hiring design and maintenance, give your designer two plans. The first shows where your network could be in a few years and the second shows what you want up on day one. See if he can handle it. Bruce Stock is right on the money when he says that each type of network has its place. BU uses lots of Ethernet in separate buildings and the broadband runs our terminal servers. Broadband gives us the campus coverage and Ethernet suits our DECnet and Unix machine environments. Broadband can link your Ethernets, provide access with broadband terminal servers to buildings with terminals but no Ethernet, and carry video, security and environmental control signals. Broadband LANs are proprietary now. This is probably a major reason broadband will be supplanted by fiber-based FDDI (the 100Mbps non-proprietary token ring standard in the works) when the time comes. You have to commit resources to make broadband work and you have to exploit its strengths (campus coverage) and minimize its weaknesses (exotic technology) by using it as a backbone system. I hope this hasn't been too long-winded or boring. Thanks for reading my musings.-- ---------------------------------------------- Kent W. England Manager, Network & Systems Engineering Boston University Information Technology 111 Cummington Street Boston, MA 02215 kwe@buit1.bu.edu ARPAnet, CSnet kwe@buit BITNET ----------------------------------------------