Is performing the checksum really that bad?
3 Apr 88 22:27:00 EST


You wrote recently that,

        Even worse is that fact that in 4bsd this [end-to-end
        checksum] is a host wide option, so if I have a single SLIP
        based client of my NFS fileserver and I want him to get
        checksummed packets, I have to checksum packets for all
        Ethernet only local users as well, users who are more likely
        to be concerned with SPEED [my emphasis] and not with data
        corruption on the Ethernet.

It occured to me that we now live in a new era: A.J. (after Jacobson).
An era in which two small Sun workstations can obtain a TCP throughput
of 8 Mbps, checksums, headers and all; and without fully consuming the CPUs!

I am NOT commenting one way or the other on the SLIP controversy.
Rather, I would like to offer the thought that the impact on performance
caused by running with end-to-end checksumming enabled may be greater than
it need be. Perhaps implementers could follow Mr. Jacobson's fine example
by revising their algorithms and optimizing their code. Even when only
modest throughputs are required, a user would still benefit from the
reduction in CPU utilization.


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