Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!edison.ge.COM!uucp From: uucp@edison.ge.COM (UNIX-to-UNIX Copy) Newsgroups: comp.os.vms Subject: Submission for mod-computers-vax Message-ID: <8704280746.AA20512@edison.GE.COM> Date: Tue, 28-Apr-87 03:46:48 EDT Article-I.D.: edison.8704280746.AA20512 Posted: Tue Apr 28 03:46:48 1987 Date-Received: Sat, 2-May-87 04:00:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 128 Path: edison!uvacs!virginia!umd5!brl-adm!seismo!esosun!ucsdhub!sdcsvax!ucbvax!CRNLNS.BITNET!SYSTEM From: SYSTEM@CRNLNS.BITNET Newsgroups: mod.computers.vax Subject: CMU/TEK TCP/IP TELNET performance Message-ID: <8704262038.AA07915@ucbvax.Berkeley.EDU> Date: 26 Apr 87 18:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 117 Doug, I had planned to delay publishing the following report until I had some WIN/VX numbers to compare, but obviously you need to know soon. 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 CMU/TEK 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.