Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!ames!ucbcad!ucbvax!CRNLNS.BITNET!SYSTEM From: SYSTEM@CRNLNS.BITNET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators Message-ID: <8705071949.AA23126@ucbvax.Berkeley.EDU> Date: Thu, 7-May-87 08:42:00 EDT Article-I.D.: ucbvax.8705071949.AA23126 Posted: Thu May 7 08:42:00 1987 Date-Received: Sat, 9-May-87 05:06:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 123 Charles, Thanks for the Ethernet utilization statistics for your Cisco terminal servers. It's consistant with what I've seen for one host based TELNET program. Unfortunately, though, it's not the whole story. The problem that we've encountered is the high CPU overhead used by at least one TELNET implementation under VMS. I am enclosing a copy of a brief test that I did recently. It's certainly not definitive, but it gives one food for thought. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) P.S. The Ethernet utilization figures were obtained by running a patched version of VMS Monitor with the command $ MONITOR ETHERNET I can send you a copy of the patch if you don't have it. S. ------------------------------------------------------------------- The following is a report of a test done using CMU/TEK TCP/IP by S.Ball on April 23rd and 24th, 1987 Executive summary: ================= If we run TCP/IP for production use, we will need a front end. CMU/TEK TCP/IP software uses an excessive amount of cpu resources for terminal support both outbound, when accessing another system, and inbound, when the local system is hosting a session. Environment: ============ 2 VAX-11/750s (LNS53 and CLE750) with FPA and 5 Megabytes of memory, running VMS 4.4 and connected with DEUNA Ethernet interfaces. The CMU TCP/IP package being tested consisted of FINGER V2.4, SMAIL V2.5, TELNET V3.0, and IP/ACP V6.0. Only TELNET and IP/ACP were actually involved in this test. Each of the tests was run for only about a minute, so the percentages aren't accurate to better than about 5% or worse. Unfortunately, that size of error is unimportant. TELNET i/o test --------------- I used a 9600 baud terminal connected to a DEC LAT-11 terminal server on Ethernet. Past studies have shown the LAT protocol to be comparable to DMF-32 connections in terms of its CPU use. First I logged into LNS53 (3 others were logged in doing nothing), and then did a TELNET to CLE750 (where 1 other was logged in doing nothing) and gave the command "TYPE DOC:*.*;*". Our DOC: directory contains many text files of various sizes. results: -------- (the actual numbers fluctuated +/- 5% or so, presumably due to disk file open overhead) The transfer used 100% of the cpu on (remote) CLE750 ==== (20% kernel, 80% user, <5% interrupt) User mode programs on on CLE750 were the TELNET server using about 50%, IP_ACP using about 15%, and TYPE using about 15%. It used 50% of the cpu on (local) LNS53 (15% kernel, 35% user, <5% interrupt) === User mode programs on LNS53 were TELNET and IP_ACP, using approximately equal fractions of the cpu, but with large fluctuations. Ethernet use went from 10Kbytes/sec to about 15Kbytes/sec. The Ethernet packet size averaged about 100 bytes, presumably 1 per record of terminal output. But, if we assume half of the i/o increase was Lat from LNS53 to the LAT-11, and half was TELNET from CLE750 to LNS53, this implies, since the terminal i/o was < 1 Kbyte/sec x 2 = < 2 Kbytes/sec, that there was > 3 Kbytes/sec of overhead somewhere. Some of the excess may have been due to other systems doing Ethernet i/o at the same time. For comparison: ============== Using DECnet SET HOST --------------------- I used the same 9600 baud terminal connected to a DEC LAT-11 terminal server on Ethernet. I logged into LNS53 (1 other user was running a cpu bound job), I did a SET HOST to CLE750 (where 1 other was logged in doing nothing), and used the command "TYPE DOC:*.*;*" On LNS53, there was no observable degredation in my terminal output due to the other job, but the other job averaged > 75% of the cpu. In contrast to TELNET use, CLE750 averaged > 85% idle. Kernel and Interrupt modes fluctuated from 2% to 10% each, apparently dominated by disk file open operations. Unfortunately, the increased load on Ethernet wasn't observable: it was already fluctuating between 35 and 45 Kbytes/sec. Using a direct LAT connection ----------------------------- Again I used the 9600 baud terminal connected to a DEC LAT-11 terminal server on Ethernet. I logged into CLE750 (there was 1 other user logged in doing nothing), and gave the command "TYPE DOC:*.*;*" CLE750 averaged > 85% idle. Kernel and Interrupt modes fluctuated from 2% to 10% each, apparently dominated by disk file open operations. Ethernet use went from about 11 Kbytes/sec to maybe 12.5 Kbytes/sec.