DTJ Number 3 September 1987 - Digital Technical Journals

Terminal Servers on Ethernet Local Area NetworksLate in 1983, significant problems wereencountered in the design ofthe Pluto and Poseidonterminal servers. The CTERM protocol, anew design of a layered DECnet protocol offloadingcharacter-processing overhead from thehost to the terminal server, proved to be morecomplex than anticipated. Measurements of message-processingoverhead and estimates of theoverhead in the DECnet-VAX software showedthat CPU consumption in the host system wouldbe a problem for keystroke editors. Existing studiesshowed that terminals were used in keystrokemodes, rather than command-line modes, morethan fifty percent of the time. Moreover, thePluto server itself was experiencing severe performanceproblems. For example, CPU saturationoccurred when running less than six terminalsat 9600 baud, even when the terminalinterfaces used direct memory access (DMA) .Finally, a number of issues, not consideredduring the requirements phase, became moreapparent:• How could a VAXcluster system be viewed asa single system rather than as individuallyaddressable nodes?• How could the terminal load be balancedacross nodes in the V AXcluster system?• How could the management of the terminalservers be automated?Thus the use of the CTERM protocol for terminalservers in both Pluto and Poseidon was halted.(In fact, the Pluto project with an RSX kernelwas used successfully as the basis for a number ofdifferent servers in the Ethernet CommunicationsServer, or DECSA, family, including theDECnet Router, DECnet RouterjX.25 Gateway,and DECnetjSNA Gateway products. The samehardware base, though with a completely rewrittensoftware kernel, formed the basis for the finalEthernet Terminal Server.) 1However, the original task still remained;therefore, an alternative solution was proposed,based upon work done using a new architecturecalled local area transport (LAT) . The LAT solutioninvolved three essential components thatwere 'unique to that architecture:• A new transport and naming architecture toreplace the DNA routing, transport, and sessionlayers• A new operating system for the terminal server• A new "port" driver for the terminal driver ofthe VMS operating systemThe Development of LATIn late 1981, the prototype of the original LATserver was developed on a VT 1 0 3 terminalserver, which contained a small Q-bus backplanewith a PDP-1 1/23 system and an Ethernet controller.(An Ethernet controller made by 3COMCorporation was used since Digital had no Ethernetproducts available at that time.) This earlywork involved quantifying the maximum character-echodelay that a person could comfortablytolerate. We learned that an experienced touchtypist encounters difficulties when the echo timeexceeds 100 milliseconds. By extrapolating fromthis fact, we deemed that the network and CPUefficiency of the entire LAT subsystem should bedramatically improved. The approach was to"procrastinate" for up to 80 milliseconds aftercharacters were received from the terminals ateach server. This delay had the very desirableeffect of reducing the number of messages processedby the Ethernet, the host systems, and theterminal servers. (Eighty milliseconds is implementableas a multiple of either the 60-Hz linefrequencyclock common in the United States orthe 50-Hz line-frequency clock common inEurope and other countries.)In early 1982, we created a VMS driver(LTDRIVER) using a dedicated Ethernetcontroller to support the LAT server prototype.By April 1982, log-in to a VMS system froma server was achieved; about two weeks later,the performance relative to the then currentmultiplexer, the DZ-11, was measured. TheLAT connection was easily able to outperformthe DZ-11 (a programmed-interrupt controller)under a wide variety of loads. Under manyloads, the LAT connection was shown to outperformthe DMF-32 (one of a number of DMAcontrollers) .In early summer 1982, we convertedLTDRIVER to the shared Ethernet port driver.This conversion allowed a single Ethernet controllerto be used simultaneously for LAT software,and DECnet and other communicationssoftware. Unfortunately, this change yielded asignificant performance degradation. At thistime, however, the VMS Development Group wasdesigning a lower-level program interface to theEthernet driver that would allow system-levelVMS usage of the Ethernet. Currently, this interfaceis used to implement V AXcluster support viathe Ethernet.74Digital Technical JournalNo. 3 September 1986