Hello Friends @ 3000-l,

Re: TCP Checksum Processing

---------------------------------------------------------Steve Barrett writes--
  There was a post a couple of weeks ago (sorry, don't remember the author and
can't find the original post) that strongly recommended enabling checksumming
for TCP in NMMGR. I considered doing this until I saw the following "Help"
information in NMMGR:

Checksum enabled (Y/N)
     Specifies whether or not check summing will be enabled in the
     local configuration. check summing causes significant
     overhead and is not normally needed for this protocol;
     therefore, HP recommends the default value (N) for this
     field unless communication to a non-HP machine is desired.
     (Note that check summing may be done anyway if determined by
     the destination path report in the network directory or by
     the values specified in the NetIPC intrinsic's, IPCCONNECT
     and IPCRECVCN.) Default Value: N Range: Y or N

  What concerns me is the "significant overhead".  We've been running with a
TCP/IP network for over 3 years with no indication of database corruption
problems. The system is a 987/200 with approximately 500 concurrent users and
heavy transaction rates. We see indications that we are approaching ever closer
to the knee of the performance curve.
  Of those who have enabled check summing, has it had a significant impact on
performance? With TCP/IP controlling packet sequencing and Ethernet controlling
collision processing, doesn't this make it less important to validate the data
with checksum processing?
  Thanks in advance for your comments.
    Steve Barrett
---------------------------------------------------------Steve Barrett writes--

  TCP Checksum disabled (ZERO) is a 3000 to 3000 only implementation and IMHO is
nonstandard (violation of RFC's).  Any non-3000 system connecting to the 3000 if
RFC compliant will initiate communications with a SYN packet with a valid TCP
Checksum and the 3000 will define the connection as Checksum enabled Y and will
reply with a SYN/ACK with a valid (non-zero) Checksum. When the 3000 connects
outbound to another system it will send a SYN packet with a ZERO Checksum and if
it receives a SYN/ACK with a non-zero Checksum, then the 3000 will define the
connection as Checksum enabled Y.   I have see one (only one) case where a
foreign system rejected our SYN packet due to invalid (zero) checksum and the
solution was to configure the 3000 network for Checksum enabled Y.

  Historically when LAN's were first introduced on the 3000, the link was in
most cases a true Local Area Network and typically made up of peer HP hosts in
the truest sense.  Link errors were very infrequent in this configuration.  As
the 3000 networking matured, so did the environment it was placed in -
mult-vendor, PC-Lan, extended WAN/LAN networks and now Internet connections.
Link errors as we know are very frequent in this configuration, hence the
absolute necessity to Enable TCP Checksum for all network connections.

  In the past when systems CPU sizes were smaller TCP checksumming was
considered an expensive operation.  The number I recollect hearing from the TCP
lab (greater than 5 years ago) was that this overhead did not to exceed 5% of
CPU.  With today's increased CPU speeds I would no longer expect this overhead
to be significant and in relationship to possible data corruption a non-issue.
I also believe code was changed to improve the performance of the TCP
checksumming which again reduced the performance significance of enabling TCP
Checksum.  I will check with my contacts and see if I can verify this.

  The plan:
    1. I would not let performance concerns scare you away from using TCP
       checksumming... Data corruption is very expensive compared to CPU cycles;
       Remember, if you are talking non-3000 to 3000 you are already using
       TCP checksumming.
    2. I will contact my TCP labs and gather their response to performance
       considerations and TCP checksumming.
    3. I will submit a SR recommending the Help Documentation be changed and
       possibly for the Checksum enabled default to change from N to Y.
    4. I would like to test a simple IPCSEND/IPCRECV between 2 3000 systems
       and time performance and monitor CPU cycles with and with out TCP
       Checksum enabled.... but I do not know if I will find the CPU cycles
       to do this...  If anyone else finds the time, please let me know of
       your results.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.