Submission for mod-protocols-tcp-ip


Unprivileged User (nobody@columbia.edu)
2 Mar 87 20:43:11 GMT


Path: columbia!cunixc!cck
From: 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: Sender: nobody@columbia.UUCP
Reply-To: 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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:43 GMT