🚀 go-pugleaf

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
+---------------
| On 3 Sep 91 04:56:41 GMT, torek@elf.ee.lbl.gov (Chris Torek) said:
| torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
| 
| That's impossible to achieve, it ignores inband formatting information
| (headers, CRC, pauses between packets) and other practical constraints.
+---------------

True, but you can get a lot closer than you seem to think. See below...

+---------------
| The theoretical maximum is a bit less than 1MB/s, and even that cannot
| in practice be achieved because the Ethernet is a simplex channel, and
| most protocols require ACKs every now and then, and thus in practice you
| cannot just pump data continuously from source to target with maximal
| size packets.
+---------------

The data rate within a packet is 1.25 MB/s. I fear you are overstating
the amount of overhead.

+---------------
| The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
| occasional bursts at 0.9MB/s.
+---------------

Hah! Our slowest systems (SGI Irix 4D/25's) can *sustain* over 0.95 MB/s
of *user* data bytes from one Unix process to another via standard TCP/IP,
and faster systems (e.g., a pair of 4D/340's) can *sustain* 1.075 MB/s.
I know, because I measured it again just a moment ago, to be sure. The
systems involved were normal equipment, the same as customers would get,
*not* in single-user mode, *were* running the X server, *were* running
the usual assortment of daemon processes [routed, mrouted, timed, inetd,
&c.], but had no heavy users except my "ttcp" job. [Oh, yes, and they
were running the just-released Irix version 4.0 software.]

I am told by our TCP developers that using the optional "IO3" I/O board
(I only had "IO2"s on my 340's), running "single-user" with no graphics or
daemons running, and with an idle net (there were 20+ other stations on
my local net doing routed and timed, &c.), they have sustained 1.100 MB/s.
O.k., so I only got 1.075 MB/s; it was under non-ideal conditions... ;-}

Let's look at what you should be able to sustain theoretically, given fast
enough hardware and software. Most Berkeley-based TCPs will transmit one
ACK per two data packets, with default window settings. The 64-bit Ethernet
preamble is 8 bytes, and the 9.6us inter-packet gap is equivalent to 96/8 =
12 bytes.  So:

     pre dst src type IP/TCP  data  CRC IPG
Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538
Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538
Ack:  8 + 6 + 6 + 2 + 20+20 + 0+(20)+4 + 12 =   64 + 20 =   84
                              ====                        ====
                              2920                        3160

There are 2920 user data bytes (not including the "pad" to bring the ACK up
to the minimum Ethernet packet size) moved per 3160 byte-times on the wire,
which is (2920/3160)*1.25 = 1.155 MB/s of *user* data, process-to-process.

If you open your TCP window size all the way to 64 KB, you'd need one ACK
per 44 packets, but to keep things moving smoothly you'd need two ACKs per
window, or one ACK per 22 data packets = 1460/(1538 + (84/22)) = 1.18 MB/s.
Now *that's* the maximum sustainable!


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311