Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!AI.AI.MIT.EDU!JBVB
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
Newsgroups: comp.protocols.tcp-ip
Subject: TCP performance limitations
Message-ID: <262400.870930.JBVB@AI.AI.MIT.EDU>
Date: Wed, 30-Sep-87 01:15:14 EDT
Article-I.D.: AI.262400.870930.JBVB
Posted: Wed Sep 30 01:15:14 1987
Date-Received: Sun, 4-Oct-87 19:38:51 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 28


    ... what are the performance limits on a TCP connection .... in which
    there are no intervening IP routers, massive availability of underlying
    bandwidth, massive computing resources in the hosts, and low noise.
    ... the hosts could be using acknowledgement strategies highly tuned for
    this specific situation.

    			Thanks, --karl--

My initial estimate would be based on the media bandwidth and the memory
bandwidth of the host.  If the memory bandwidth of the host limits, then
I would expect the data rate will be on the order of the memory bandwidth
times the number of times the data must be copied on the way out (count DMA
and the checksum, please).  If the net bandwidth limits, I would guess
somewhere between 40% and 80% of the network bandwidth, depending on the
architecture (CSMA/CD maybe towards the low side, well-implemented Token
Passing maybe towards the high side?).

Memory bandwidth definitely dominates on the implementation I am most
familiar with.  We recently unrolled the TCP checksum loop, and a ~35%
speed improvement there produced a ~15% overall throughput increase on
memory-to-memory TCP.  This got us up to 1.4 Mbits/sec between two 8Mhz
AT clones on a lighty-loaded Ethernet (with 3rd-generation boards - LAN
controller chip & multiple packet buffers, but no processor).  40% of a
4.3-modified Sun (3.5 Mbits/sec per a recent posting)...

James B. VanBokkelen
FTP Software Inc.