how fast should TCP go?

Craig Partridge (craig@NNSC.NSF.NET)
Wed, 26 Oct 88 09:16:43 -0400

Van Jacobson's recent note reminded me of a question I've been mulling
over on and off for a while: Is there a simply way to estimate how
fast your TCP should be able to go on a given machine?

The question interests me because I'd like some way to figure out if
someone comes up to me and says "I've gotten the TCP on a Bozo-box
to run at 10mbits/sec" whether that's good or bad. In other words,
given a few details of the Bozo-box architecture I'd like to be
able to make a rough estimate of how fast its TCP will go (without
having to resort to the micro-second analysis that Van and Dave
Borman are doing). One advantage of such an estimate is that one
can spec a design and say "that should go at X bits/second."

The best approximation I've been able to come up with is the checksum.
Figure out how fast the box can checksum data and that's your maximum
speed. Furthermore, if your network hardware and operating system are
any good you ought to get close to that value. The logic is that all
other protocol operations are O(1) except for a memory copy that can
be done at the same time with the O(m) checksum (m is the message length).
The other nice thing about the checksum is that it is easy to compute
a rough guess at the maximum checksum speed -- its usually MIPS * word size.
(see RFC 1071 for adding with word sizes > 16-bits). Some computers
don't follow this paradigm (the checksum on a Cray is vectorized and if
memory is slow, then the effective MIPS may be less than advertised) but
most come close, and it may be a handy rule of thumb.

Anyway, this idea has been knocking around in my head long enough I
thought I'd let it out and see if people want to beat me up for it.
(Happy to take blows if it gets us closer to a good way to approximate
the expected TCP performance).


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