Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!COLUMBIA.EDU!nobody
From: nobody@COLUMBIA.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8703022043.AA02103@columbia.edu>
Date: Mon, 2-Mar-87 15:43:11 EST
Article-I.D.: columbia.8703022043.AA02103
Posted: Mon Mar  2 15:43:11 1987
Date-Received: Wed, 4-Mar-87 00:07:06 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 58
Approved: tcp-ip@sri-nic.arpa

Path: columbia!cunixc!cck
From: cck@cunixc (Charlie C. Kim)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Ultrix TCP/IP
Message-ID: <4410@columbia.UUCP>
Date: 2 Mar 87 20:43:10 GMT
References: <8703021756.AA15720@ucbvax.Berkeley.EDU>
Sender: nobody@columbia.UUCP
Reply-To: cck@cunixc.UUCP (Charlie C. Kim)
Distribution: world
Organization: Columbia University Center for Computing Activities
Lines: 45

In article <8703021756.AA15720@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes:
>The following is a trace (excelan monitor) of a PC communicating to a GPX
>micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other
>...
>
>QUESTION:
>   Why does Ultrix wait about 5 seconds after the PC ACK's to send it's
>next packet? Remember there are no gateways and almost noload on the
>network or GPX.
>

I'm not sure what software you're running on your pc or what version
of ultrix you are running, but both BSD 4.3 and Ultrix 1.2 delays
sends by the TCP 'PERSIST' timeout if the window is too "small" (e.g.
segment to be sent is "larger" than remotely advertised window).  This
might have been the case in Ultrix 1.1 and is probably the case in
Ultrix 2.0.  The PERSIST timeout is around 5 seconds.  The tcp
segments resulting from the cat output are probably pretty large, so
in the following you can see that the delay happens when the window
advertised by the PC TCP/IP is quite small - probably quite a bit
smaller than the segment that the Unix TCP wants to send.

>2    : CFB/OUT
>ether: IP    02-60-8c-10-46-46 -> aa-00-04-00-07-04    64        6.981    6.981
>   ip: TCP   01.004646 -> 01.00001f
>  tcp: 7464    -> TELNET   ACK
>  tcp: seq:        40  ack:  64807459  win:   82  len:    0
>
>3    : CFB/IN
>ether: IP    aa-00-04-00-07-04 -> 02-60-8c-10-46-46   140     4998.996  ***.***
>   ip: TCP   01.00001f -> 01.004646
>  tcp: TELNET  -> 7464     ACK
>  tcp: seq:  64807459  ack:        40  win: 4096  len:   82
>    0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61  |ay = XOpenDispla|
>...

Enough of the analysis, what you probably want is a workaround which I
can offer for the MIT version of PC/IP: simply set the telnet low
window close to the telnet window using custom and you'll find things
a lot more zippy.  (This I discovered by experimentation much before I
tried to figure out what was really happening).

Charlie C. Kim
User Services
Columbia University