Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!ucbvax!CSL.SRI.COM!AUERBACH
From: AUERBACH@CSL.SRI.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: More on TCP performance
Message-ID: <8710020304.AA00423@ucbvax.Berkeley.EDU>
Date: Thu, 1-Oct-87 22:56:50 EDT
Article-I.D.: ucbvax.8710020304.AA00423
Posted: Thu Oct  1 22:56:50 1987
Date-Received: Sat, 3-Oct-87 09:07:22 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 24

Thank you all for all the comments.

It seems that if one can get a net with high enough bandwidth,
low enough error rate, and short enough delay, that TCP could, in
theory,	consume a significant portion of the available bandwidth.

An example of the net that raised my initial question is the Los Alamos CP*
net which will run its links at 640Mbits/sec.  Total capacity of the
net will be on the order of 20G (yes that's a 'G', not an 'M') bits/sec.
Lengths are short, so delays will probably be less than a few thousand
bit times (i.e. much less than a millisecond.  The end nodes will be
Cray X-MP, Cray 2, and faster.

(At 640Mbits it only takes about 8 milliseconds to transmit a full
segment!)

What bothers me the most is that we've had HYPERchannels for a long
time and 80meg Proteon rings for a while, but the highest TCP
value I heard was about 17megabits.  Why the discrepency?  Is it something
intrinsic to the TCP protocol (and probably in ISO TPx as well) or
in the implementations or hardware?

		--karl--
-------