Re: IP Checksumming

Torbjorn Lindgren (tl@funcom.no)
Fri, 22 Nov 1996 10:28:29 +0100 (MET)


On Thu, 21 Nov 1996, Richard B. Johnson wrote:
> This is one of those "ya...but". Situations. The code to which I refer
> transfers image data on a CAT-Scanner via TCP/IP Ethernet at 90 percent
> of the theoretical 10 megabytes/second bandwidth. The TCP/IP implimentation
> is complete, i.e., no short-cuts, with the top-level interface being
> Berkeley Sockets. The machines are 486/DX-66. I tested most of the

So? Even a straigh forward checksumming algorithm shouldn't limit that on
a DX2-66... The big win is in not doing the copy and the checksuming
separately.

With 10MBit ethernet you would probably have to use a *386* before we
could start talking about the need to optimize the check-suming *parts*.

Besides, someone claims to have measured 10.49 MB/s on a 100 MBit
fast ethernet using Linux. A quick calculation shows that this is in the
order of ~85 % of full fast ethernet bandwidth...

This is more than you have claimed to achieve, and on a medium 10x the
speed of your medium. The CPU as probably faster, but it's unlikely that
it was *more* than 10x faster than a DX2-66! (Know any good sources for
400 MHz Pentiums?)

> Of course there IS a difference. This TCP/IP implementation only has
> ONE Client and ONE Server so there are never any collisions. There are,
> however, the usual number of retransmissions because the SNICS (serial
> network interface chips) are usually faster than the software so some
> packets do get lost.

If the network interface chips is faster than the software it's time to
take a look at the software again.

-- 
Torbjörn Lindgren
Langkaia 1, N-0150 Oslo, Norway     Phone: +47 22420102
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.