DTJ Number 3 September 1987 - Digital Technical Journals

Terminal Servers on Ethernet Local Area NetworksA second equally important decision was madeearly in the project: the product managersdefined and then enforced a very aggressive costgo:'ll in terms of dollars per connection. That goalwas set in two passes. In the first, the engineersdid a preliminary cost analysis, taking intoaccount competitive pressures and currentlyavailable technology. In the second, the productmanagers decided the original goal was too high,lowered it, and then challenged the engineers tomeet it. This challenge gave the engineers everyincentive to squeeze cost out of the design .Although some cost reductions seemed quiteinsignificant and not worth the effort, in the endthe old adage of "watch the pennies and i:he dollarswill watch themselves" proved to be true.The insistence on meeting the cost goal also preventedus from adding "bells and whistles," withtheir associated costs and complexity, to therequirements list as the project progressed.Starting system design, we immediately facedan inescapable trade-off in the design options. Inthe ideal case, the cost per terminal to connect asingle isolated terminal should be the same ascost per terminal to connect, say, 16 terminals.That is, the cost steps should be uniform as terminalsare added to the system. Unfortunately,some of the costs in a server system are essentiallyfixed. For example, the power and packagingcosts are approximately the same whether aserver accommodates one terminal or four.These fixed costs result in a relatively large initialcost step, followed by smaller steps as terminalsare added, followed by another large stepwhen an additional server is added. We realizedthat a compromise was needed between step sizeand the potential for amortizing fixed cost overseveral terminals. As the design progressed, wedecided that eight terminals per server providedan acceptable step size that allowed us to meetthe cost-per-line goal.Work started on the hardware design witha clear cost goal, but with no preconceived· requirements for the implementation. It seemedfairly obvious that an eight-line server could bebuilt on a single printed circuit board. Sincethere is a substantial expense simply in connectingmultiple boards, we decided very early thatdirectly incorporating any pieces of existingproducts was too expensive. The server wouldbe a single board designed from scratch,although we were free to borrow design ideasfrom other products. We also decided to use onlyhigh-volume, and therefore inexpensive, componentswhere possible - a decision driven partiallyby the desire to shorten the design time.Mter these decisions, work started in earnest.One of the most important issues was makingsure there was enough processing power. Sincewe had confined the problem to a specific application,we could size the processing requirementsquite accurately. Pluto had to deal withmany potential applications and an expandablenumber of terminals, Poseidon with exactly oneapplication and eight terminals. Pluto has onemain processor with assist processors added asterminals are added; Poseidon did not have toexpand and needed only one processor ifit hadsufficient power. At this time, several extremelypowerful 16-bit processors became generallyavailable. We evaluated them, including somefrom Digital as well as other vendors. SincePoseidon would not be programmed by customers,the extensive PDP- 11 and VAX instructionsets were not really needed. We decidedfinally to use the Motorola 68000 chip, whichwas the lowest cost, most readily availablemicroprocessor with sufficient power.As the design progressed, we considered everypossible cost reduction option. For example, thedynamic RAMs are refreshed by software sincesufficient processing time exists to do that; thecost of refresh hardware could thus be eliminated.Chips were selected to perform multiplefunctions whenever possible. For example, theterminal interface (UART) chips have integraltimers used to control the software refresh, thetimer interrupt, and the watchdog timer. Essentially,the interrupt logic uses very little externallogic to tum around the interrupt priority levelto generate the vector address.Thus the design resulted in an extremely lowcost,fixed-function terminal server, the DECserver 100, which has proven to be, by far, themost popular member of Digital's terminalserver fa mily. Figure 1 depicts the initial LATproduct.The LAT ArchitectureThe LAT ProtocolOne initial goal of the LAT architecture. was toconnect terminals to host systems using the Ethernetas a data link. Even today, LAT is•still usedprimarily for connecting terminals to hosts.However, its application has spread to connect-76Digital TecbnicaljournalNo. 3 September 1986