[comp.protocols.tcp-ip] Question: Maximum speed of TCP/IP

lap@udel.EDU (Larry Pearlstein) (07/09/89)

I would appreciate any information about the maximum practical
data transfer rate using TCP/IP protocols on an unloaded, two
node Ethernet (10 Mbps) in moving large (~50 MBytes) blocks of
data between, say, two fast '386 based machines.  I saw a demo
of ftp between a 386 and fast AT using smart (Excelan) cards
which displayed a throughput of 40 KBytes/sec!  If disk access
is minimized or eliminated (perhaps just peer-peer communication
using TCP sockets) is it feasible to achieve 400 KBytes/sec?

Mail replies will be especially appreciated.

				Larry Pearlstein
				lap@huey.udel.edu

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/10/89)

In article <19330@louie.udel.EDU>, lap@udel.EDU (Larry Pearlstein) writes:
> ...If disk access
> is minimized or eliminated (perhaps just peer-peer communication
> using TCP sockets) is it feasible to achieve 400 KBytes/sec?
> 				Larry Pearlstein
> 				lap@huey.udel.edu

400KBytes/sec, as measured by ttcp (doing user-process-to-user-process)
on a quiet ethernet is very slow--at least for current, fast workstations.
It does help to have user buffers >= 1KB.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

ljm@TWG.COM (Leo J McLaughlin) (07/11/89)

Larry,

>I would appreciate any information about the maximum practical
>data transfer rate using TCP/IP protocols on an unloaded, two
>node Ethernet (10 Mbps) in moving large (~50 MBytes) blocks of
>data between, say, two fast '386 based machines.  I saw a demo
>of ftp between a 386 and fast AT using smart (Excelan) cards
>which displayed a throughput of 40 KBytes/sec!  If disk access
>is minimized or eliminated (perhaps just peer-peer communication
>using TCP sockets) is it feasible to achieve 400 KBytes/sec?

For '386 machines 400KBytes/sec peer to peer is very slow.  Even
without implementing TCP header prediction our FTP transfer speeds
are in the 330KBytes/sec range (with a dumb 3c503).  One thing to
bear in mind is that with smart boards the host's processor doesn't
get to do any of the protocol work -- a performance hit if the host's
processor is significantly faster than the board's.

If you are implementing or modifying a TCP/IP protocol stack and are
concerned about performance there are a few quick things you should 
be looking at.  Make sure your checksum routine is unrolled and your
algorithm is fast.  Negotiate a large MSS when on the same network.
Make sure your TCP flow control mechanisms allow applications to keep
the data pipe full.  And, in general, make sure reciept or tranmission
of the next segment in an open connection happens as quickly as possible.

enjoy,
leo j mclaughlin iii
Project Manager
The Wollongong Group
ljm@twg.com