martillo@ATHENA.MIT.EDU (05/06/87)
Does anybody have figures for obtained packet rates for asynchronous terminal concentrators over ethernet? I mean the configuration where the host has an ethernet interface and lives on the same LAN as the asynchronous terminal concentrator which supports say 8-16 terminals. I think DEC has a product of this type called LAT (LAN Asynchronous Terminal?). I would suspect that because protocol layers 3 and 4 would not need to be implemented that better performance would be obtained than with telnet or rlogin based terminal concentrators (although internetting would be impossible). I would still be interested in figures for telnet or rlogin style terminal concentrators as well. Also while the maximum packet rate at the concentrator is of interest, I would really like to know what sort of packet rates people consider good on the host side. Yakim Martillo
root@TOPAZ.RUTGERS.EDU (Charles Hedrick) (05/06/87)
I just took a look at some statistics from three of our Cisco terminal servers. Since it's 3am, packet rates wouldn't show much, but I have some other data which is probably in the long run more useful. This shows the total number of packets in and out for each session, the total number of bytes, and the number of packets with data. By looking at the fraction of packets with data, you can get a feeling for how much you are paying for TCP ack and window updates. Note however that even with LAT, there surely has to be some sort of acknowledgements, so it can't be 100% efficient either. The original data contains a lot more info about the innards of the TCP protocol handling, but I have omitted it as it didn't seem relevant to this discussion. It looks like well over half (typically over 2/3) of the packets received have data (i.e. are not just acks), and the amount of data per packet is fairly high. It looks like around half, or maybe slightly less of the packets sent have data, and as you would expect it is about one char per packet. (A couple of the connections have been idle for long periods, so you see packets that aren't doing much.) It looks to me like this is about as efficient as one can hope for. It looks like acks for stuff we send typically gets piggybacked on the echo, but the stuff that comes back requires separate acks. This is what you'd expect with a simple model of what is going on, and is presumably going to be the same for any protocol that is designed to use unreliable networks. The number of characters per packet also seems good. Obviously I can't compare this with LAT without seeing data on LAT, but there doesn't seem to be a lot of room for improvement. dialup to Sun (4.2 IP, 4.3 beta TCP), though one gateway Rcvd: 4694 (out of order: 0), with data: 4374, total data bytes: 160181 Sent: 6456 (retransmit: 1), with data: 3988, total data bytes: 4220 dialup to Pyramid (4.3 TCP/IP, with telnetd in the kernel) Rcvd: 1981 (out of order: 0), with data: 1634, total data bytes: 119314 Sent: 1626 (retransmit: 0), with data: 824, total data bytes: 900 hardwired to Sun, through one gateway Rcvd: 2472 (out of order: 0), with data: 1265, total data bytes: 114771 Sent: 2489 (retransmit: 0), with data: 175, total data bytes: 191 hardwired to Pyramid Rcvd: 12195 (out of order: 0), with data: 7116, total data bytes: 88935 Sent: 9044 (retransmit: 0), with data: 6957, total data bytes: 7206 hardwired to Sun, through one gateway Rcvd: 671 (out of order: 0), with data: 406, total data bytes: 10684 Sent: 834 (retransmit: 0), with data: 340, total data bytes: 349 hardwired to DEC-20 Rcvd: 14579 (out of order: 0), with data: 410, total data bytes: 54371 Sent: 492 (retransmit: 0), with data: 207, total data bytes: 249
CERF@A.ISI.EDU.UUCP (05/06/87)
Yakim, LAT stands for the name of the protocol used by Digital to support terminal to host access over an ethernet. Dunno what rates you can expect, but we were supporting 35-50 concurrent virtual terminals from a microvax II across an ethernet to a bunch of hosts. Oh, each VT was operating between 1200 and 2400 bps but the protocol to the microvax was line at a time X.25. Vint
SYSTEM@CRNLNS.BITNET.UUCP (05/07/87)
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.SYSTEM@CRNLNS.BITNET (05/08/87)
Thanks for the information about WIN/VX performance. My tests of the CMU/TEK TCP/IP package were using CMU's "shared DEUNA" code. DECnet and LAT were also using the same hardware. CMU's software uses DEC's XE driver, creating additional logical devices. Obviously, I'll have to try to do another test using a separate DEUNA. Selden
ROODE@BIONET-20.ARPA (David Roode) (05/08/87)
The numbers you quote are extremely similar to those sent by David Kashtan over a year ago concerning the affect of context switching on performance of Telnet service. Kashtan is the implementor of a package which includes IP and TCP and TELNET and which has now become available from SRI International. This package has been in existence for a very long time, and his previous message, if memory serves me, concerned some experiments he did with a non-Kernel implementation of the above protocols. The problem is that the CPU can be consumed by the context switching needed for character at a time I/O as common in Telnet. Kashtan's experience was that a single 9600 baud Telnet connection could consume nearly an entire 780. Again, this is subject to my recall. However, his implementation handles things very differently and runs in Kernel mode. As a result it is much more efficient. We have it here on MicroVaxes and it is the primary means for users to use the machine, i.e. there are no hardwire terminal ports to speak of, so everyone comes in via cisco boxes. We note no problems with the Telnet connections to the microvax consuming excess resources, although we typically only have 6-8 at a time of peak usage. -------
melohn@SUN.COM.UUCP (05/08/87)
Local Area Terminal is a DEC propritary protocol. Hypothetically, if you were to combine the I/O from several terminal sessions into a single message between each server and host pair, you might very well exceed the figures Charles is seeing with Cisco Terminal concentrators, espcially when multiple sessions are communicating with the same host. If you limited the frequency of how often you sent messages to each host to some value (like 80ms), and required the host to in most cases send a message only in reply to a message from the server, the amount of traffic would be further reduced.
leres@ucbarpa.Berkeley.EDU.UUCP (05/08/87)
I'm not familiar with the cmu/tek vms tcp/ip. Does it use the Salkind epacket/elink code? The (low) performance you quote in your posting leads me to believe so. Salkind's code was the first to share the deuna with decnet. Basically, a process (elink) hangs reads on the deuna and on a raw internet socket. When a packet comes in off the wire, elink gets it and then writes it onto the raw socket. It goes through the internet code, comes out via the indriver, and arrives in the users buffer. An out bound packet goes the other way; from user process to internet kernel to elink process to deuna driver. At the time it was first implemented, elink was great; you could have decnet and internet on your machine without buying two ethernet interfaces. But obviously, having data pass through the elink process isn't very efficient. Decnet uses an (undocumented) internal interface to the ethernet driver called the alt start facility. This facility allows kernel use of the ethernet driver. I recently rewrote epacket for the Wollongong Group's WIN/VX product. Now, packets go directly from the ethernet driver to the internet code so things runs faster and uses less cpu time. If I login to a 9600 baud hardwired terminal on a 780 and telnet to a 750 and do "help /nopage * * *", the 780 is 95% idle and the 750 is 60% idle. On occasion, I have achieved 85 Kbytes/sec between the VMS 780 and a 4.3 Unix 780. I've heard that Kashtan rewrote epacket to use the internal "ffi" interface to the ethernet driver for SRI's Multinet product. I'd expect it to also be much faster than an elink process implementation. I don't sell or distribute these products. If you are interested in them, please contact TWG or SRI. Craig
lamaster@ames.UUCP (Hugh LaMaster) (05/08/87)
In article ... SYSTEM@CRNLNS.BITNET writes: > >The problem that we've encountered is the high >CPU overhead used by at least one TELNET implementation under VMS. >The following is a report of a test done using CMU/TEK TCP/IP : >CMU/TEK TCP/IP software uses an excessive amount of cpu resources >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 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%. One part of the results surprised me, based on my experiments. I have performed essentially the same experiments, using Wollongong TCP/IP on VMS. a terminal uses about 5-6% in user state. However, during the same period, total system usage (user + interrupt + kernel) was about 15%. This was true with both telnet and a direct wired terminal. Two points: 1) Wollongong TCP/IP is clearly more efficient than the TCP/IP you used; and 2) I saw higher overhead from direct wired terminals than you did (I am wondering why right now :-) ). Anyway, I was concerned about telnet overhead myself, but found no observable difference between network and direct wired. This surprised me, I admit; Wollongong has improved a great deal in the last releases. An interesting part to me was discovering just how expensive terminal I/O is on VMS. 7 9600 baud terminals at full output saturated a 785... I think it is definitely a question which should be addressed more carefully by the terminal server vendors. Some implementations work fine, others seem to be a problem. Most of the vendors don't seem to have looked at this as carefully as I would have expected.