SYSTEM@CRNLNS.BITNET (04/26/87)
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.