Subject: | |
From: | |
Reply To: | HOFMEISTER,JAMES (HP-USA,ex1) |
Date: | Tue, 15 Aug 2000 11:17:43 -0600 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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%
=================
|
|
|