[comp.protocols.tcp-ip] Terminal server efficiency

eshop@saturn.ucsc.edu (Jim Warner) (11/16/87)

How important is the offered TCP window size for Ethernet
terminal servers?  

Our Bridge LS1 terminal server offers a maximum window size
of 164 bytes.  Our Micom terminal server offers a 384 byte
window.  The small window forces our computers to send a full
screen update as many small packets instead of fewer larger
packets.  It seems to me that this is expensive in terms
of CPU bandwidth both for the connected computer and any
intervening gateways.  What do people think?  Is this important?

Here's some data.  I logged in to a 4.3BSD computer, read a 7
screen file (154 line, 10430 byte) with unix 'more' and logged out.
In all cases the terminal baud rate was 9600.  "Total packets"
includes those necessary to log in and give the commands.

Terminal           software      Max Offered        Total packets
attached to        version       rcv window         (both ways)

Bridge LS1         13000          164                481
Micom NTS-100      V1.3-AC        384                241
VAX 750            4.3BSD        4096                159


Our Micom NTS-100 is running software that is still in beta test.
The production software offers a 320 byte window.

hedrick@ATHOS.RUTGERS.EDU.UUCP (11/19/87)

Our tests also showed that a small window can significantly increase
the CPU time on hosts that are talking to a terminal server.  Thus I
regard small windows as a significant problem.

JBVB@AI.AI.MIT.EDU.UUCP (11/20/87)

If the window is smaller than the MSS, the MSS doesn't matter much - you'll
never see a packet bigger than the window.  I have observed the 164-byte
window feature in Bridge, and the fact that at least one of their products
only sends 82 bytes (I hesitate to guess why..) in a packet, no matter how
much output is pending.  This is a box that serves as a milking machine,
attached to a host via async lines.

I think window (or MSS, whichever is the limiting factor) is an important
consideration.  I have found that it affects throughput a lot, even in
telnet output situations.

jbvb

lamaster@pioneer.arpa (Hugh LaMaster) (11/23/87)

In article <8711191851.AA13481@athos.rutgers.edu> hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) writes:

>regard small windows as a significant problem.

Does anyone know how the Encore Annex behaves?





  Hugh LaMaster, m/s 233-9,  UUCP {topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

(Disclaimer: "All opinions solely the author's responsibility")