HP3000-L Archives

August 2000, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Rick Clark <[log in to unmask]>
Reply To:
Date:
Tue, 15 Aug 2000 15:27:24 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (253 lines)
Thanks James. I really appreciate you taking the time to do this. When this
thread first started I questioned why HP would recommend that the setting be
'N' but the consensus was to leave it a "Y'. Your research helps me better
understand the value of this setting.

Rick Clark
Senior Systems Analyst
WW&R
Cleveland, Ohio


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of HOFMEISTER,JAMES (HP-USA,ex1)
Sent: Tuesday, August 15, 2000 1:18 PM
To: [log in to unmask]
Subject: [HP3000-L] TCP Checksum performance


Hello Folks @ 3000-L,

Re: TCP checksum

The question of TCP checksum came up a while back... and several people
have been frightened off by the NMMGR help warning about the performance
of this configuration value.  This weekend I took the time to research
the performance implications of TCP checksum on a variety of HP e3k CPU
sizes, here is the data and my recommendations.

First of all I am taking about the "Checksum Enabled" configuration
parameter found in NMMGR at Path:  NETXPORT.GPROT.TCP.

If you press [F7] Help you get the following info on this parameter:

+------------------------------------------------------------+
Checksum enabled (Y/N)
     Specifies whether or not checksumming will be enabled
     in the local configuration.  Checksumming 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 checksumming
     may be done anyway if determined by the destination
     path report in the network directory or by the
     values specified in the NetIPC intrinsics, IPCCONNECT
     and IPCRECVCN.)
     Default Value: N
     Range:  Y or N
+------------------------------------------------------------+

I will start by describing my test environment and procedures and give
you all of the disclaimers and of course YMWV (Your Mileage Will Vary)
since we are talking about performance.

The test systems I selected are:

  1. Ector 917LX on MPE/iX 6.0 with all network Beta patches installed
  2. Lance 937SX on MPE/iX 5.5 with all network Beta patches installed
  3. Kitt  967SX on MPE/iX 6.0 with some network Beta and GR patches.
  4. Kato  959/200  MPE/iX 5.5 with some network Beta and GR patches.


The Ector and Lance machines are connected together by twisted pair
MAU, HUBs and Bridges.

The Kit and Kato machines are connected together by thin MAU and thin
cable.

The test I selected is 20,000 packets of 1408 bytes driven by the XPPERF
sockets program which supports the ability to specify TCP Checksum ?
yes/no.  The raw data I have used to identify the performance of TCP
Checksum enabled/disabled is the output of the XPPERF program and the
CPU Seconds recorded for a batch job running XPPERF.  This test was run
one pass at a time.


In all of my test the machines under test and the network links under
test were idle... not much going on at HP on Saturday from 12:00 to 4:00
am. My test sample size is 3 samples with each configuration.

The disclaimers... This test is performed "ONLY" to determine the
difference between TCP Checksum enabled yes/no.  This test does not with
any accuracy identify the LAN or system performance differences between
CPU sizes.  The comparison that can be made "apples to apples" is the
difference in execution performance of the XPPERF program with Checksum
enabled and Checksum disabled between the same two machines.  For the
purposes of this test I have verified we did not experience TCP
retransmissions or buffer overruns which would of significantly altered
the results.

The finding is on my low end 917LX is that data-transfer performance
with TCP checksum enabled was significantly slower in the range of 7-8
percent slower, but the CPU impact was only in the range of 2-3 percent
higher overhead.

My finding on my next fastest machine a 937SX is that data-transfer
performance with TCP checksum enabled was also significantly slower in
the range of 3-4 percent slower and the CPU impact was also in about
the same range of 2-3 percent higher overhead.

The finding on my next next fastest machine a 967SX is that
data-transfer performance with TCP checksum enabled is insignificant
and the CPU impact is also insignificant.

The same is true of my finding on my very fastest machine a 959-200 is
that data-transfer performance with TCP checksum enabled is
insignificant and the CPU impact is also insignificant.

Before I say another word, I must emphasis YMWV (Your Mileage Will Vary).
If your machine is already 99.9% utilized and none of your TCP
connections are currently using TCP Checksum, then 2-3 percent higher
CPU overhead is going to be noticed.  If your file transfer already
takes 2 hours to run, then 7-8 percent slower is going to be noticed.

One point to keep in mind is this discussion is only appropriate for
3000-to-3000 connections.  If a non-3000 system is connecting to your
system and performing communications via sockets or a FTP file transfer
or a Telnet session you are already using TCP Checksum and their is no
way to turn it off since TCP Checksum is the "industry" RFC standard.

Now if you do have 3000 to 3000 connections I again would urge you to
enable TCP Checksum.  I am always willing to pay an increase of 2-3
percent higher CPU overhead or 7-8 percent slower file transfer rate
with the insurance of avoiding data corruption.

Here is the raw data from my XPERF testing 3 passes per CPU type.

FYI: This data is not statistically accurate... many more than 3 test
cases per CPU type would be necessary, but I think the results are close
enough for my purposes in this investigation.

P.S. I will be submitting these test results to a SR and request the
default of Checksum enabled (Y/N) be changed to "Y" yes and the help
documentation be updated.  Done, SR = 8606155933.


Regards,

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




ector 6.0 917LX -> lance 5.5 937SX

 Ending      Buffer   Turnaround                       Elapsed      CPU
TCP
 step        size     time/msg    MBits/   KBytes/     time
CKSM
 time        (bytes)  (seconds)   second   second      (seconds) (seconds)
 ----------  -------  ----------  -------  ----------  ---------    ----
---
  17901064      1408    0.003465     6.35      793.65       69.3    48
NO
  18159109      1408    0.003495     6.29      786.84       69.9    49
NO
  18289410      1408    0.003450     6.38      797.10       69.0    48
NO
                                               ------       ----    ----
                                               792.53       69.4    48.3

  17301762      1408    0.003525     6.24      780.14       70.5    49
YES
  17574919      1408    0.003605     6.10      762.83       72.1    50
YES
  17765638      1408    0.004105     5.36      669.91       82.1    50
YES
                                               ------       ----    ----
                                               737.62       74.9    49.6

 Percentage Change                              -7.4%       +7.9%   +2.6%
 =================


lance 5.5 937SX -> ector 6.0 917LX

  Ending      Buffer  Turnaround             Elapsed       CPU    TCP
   step        size    time/msg    KBytes/     time               CKSM
   time      (bytes)   (seconds)   second    (seconds)  (seconds)
 ----------  -------  -----------  -------  -----------    ----   ---
 966058568     1408       0.0041   679.01         81       56     NO
 966058683     1408       0.0041   670.73         82       57     NO
 966058857     1408       0.0041   670.73         82       57     NO
                          ------   ------         ----     ----
                                   673.49         81.6     56.6

 966059016     1408       0.0043   639.53         86       60     YES
 966059204     1408       0.0043   647.06         85       58     YES
 966059337     1408       0.0041   670.73         82       56     YES
                          ------   ------         ----     ----
                                   652.44         84.3     58.0

 Percentage Change                  -3.1%         +3.3%    +2.4%
 =================


kitt 6.0 967SX -> kato 5.5 959-200


 Ending      Buffer   Turnaround                       Elapsed       CPU
TCP
 step        size     time/msg    MBits/   KBytes/     time
CKSM
 time        (bytes)  (seconds)   second   second      (seconds)  (seconds)
 ----------  -------  ----------  -------  ----------  ---------    ----
---

 220470790      1408    0.002755     7.99      998.19       55.1    31
NO
 220673799      1408    0.002755     7.99      998.19       55.1    31
NO
 220802824      1408    0.002750     8.00     1000.00       55.0    31
NO
                                               ------       ----    ----
                                               998.79       55.1    31

 220935938      1408    0.002750     8.00     1000.00       55.0    31
YES
 221059844      1408    0.002750     8.00     1000.00       55.0    31
YES
 221131784      1408    0.002750     8.00     1000.00       55.0    31
YES
                                               ------       ----    ----
                                              1000.00       55.0    31

 Percentage Change                              -0.1%       -0.1%   +0.0%
 =================


kato 5.5 959-200 -> kitt 6.0 967SX

  Ending      Buffer  Turnaround             Elapsed       CPU    TCKP
   step        size    time/msg    KBytes/     time               CKSM
   time      (bytes)   (seconds)   second    (seconds)  (seconds)
 ----------  -------  -----------  -------  -----------    ----    ---
 966155256     1408       0.0027  1000.00         55      14      NO
 966155339     1408       0.0027  1000.00         55      14      NO
 966155418     1408       0.0027  1000.00         55      14      NO
                                   ------       ----    ----
                                  1000.00         55      14

 966154919     1408       0.0027  1000.00         55      16      YES
 966155031     1408       0.0027  1000.00         55      14      YES
 966155115     1408       0.0027  1000.00         55      13      YES
                                   ------       ----    ----
                                  1000.00       55.0    14.3

 Percentage Change                  +0.0%       +0.0%   +2.0%
 =================

ATOM RSS1 RSS2