We had a TCPIP performance issue when we upgraded from
OS/390 2.7 to 2.10. The conclusion of that the problem is attached
below (from an IBM ETR record).
This could be another lead to follow ....
"... from looking at the trace and the dump, we see that
Optimal max segment size is 65,495 bytes, the Send Buffer Size is
65,536 bytes and the amount of data that the application is giving
tcpip on each send is 32,003 bytes. For fast local sockets the
Optimal max segment size is determined from the Send Buffer Size.
In release 10, tcpip started enforcing the Nagle algorithm.
The Nagle algorithm says that if we have sent a packet where the
data size is less than the max segment size and it has not been
acknowledged, we should avoid sending more data unless we can send
a full sized segment.
In the case that we are looking at, the data that is available to send
will always be less than the max segment size. Therefore tcpip waits
for an acknowledgement on each packet before sending the next packet.
The receiving side always waits for 2 packets before sending an
acknowledgement or the delay timer to times out.
This is what is causing the slow performance.
There three ways to get around this problem.
1. Make the max segment size, by changing the send buffer size,
equal to or less then the send data size that the application
is giving to tcpip.
2. Turn the Regal algorithm off.
This algorithm can be turned on and off by the application with
the SETSOCKOPT macro with option TCP_NODELAY.
3. Turn off Delay Acks by coding NODELAYACKS on the PORT statement
for the port for the receiving application. "
I do not know about hipersockets by may be z/OS is
using the fast local sockets (tcpip traffic within an OS instance)
for the hipersocket interface too.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
