Showing results for 
Search instead for 
Did you mean: 

TCP/IP settings.

Go to solution
Leif Halvarsson_2
Honored Contributor

TCP/IP settings.


We have some performance problems when backing up a NetWare client to a HP-UX server. In NetWare there is a setting which affects performance:

Is there any corresponding setting in HP-UX ?
Patrick Wallek
Honored Contributor

Re: TCP/IP settings.

I have never seen or heard of anything like that in HP-UX. I just browsed through the ndd parameters and I didn't see anything there either.

'man ndd' for more information on it. You can also do an 'ndd -h sup' and an 'ndd -h unsup' to get information on supported and unsupported ndd parameters.
John Poff
Honored Contributor

Re: TCP/IP settings.

Hi Leif,

I looked at 'ndd' but I didn't see anything specifically covering that setting. Do you have any details about what that setting does in NetWare? Maybe we can correlate between that and what is available from ndd.


Leif Halvarsson_2
Honored Contributor

Re: TCP/IP settings.

I found this on the Novell site.

The customer was able to increase backup performance dramatically by setting.
Set these on the console and then put them in SYS:\SYSTEM\AUTOEXEC.NCF (no reboot needed)

1. Are there some secondary effects to turning this OFF?

No, they are not. The TCP delay ACK is defined in the corresponding RFC
and it was provided to optimize low bandwidth connections. When the TCP
layer gets the data; it removes the TCP header and notifies the upper
layer that data can be picked up. Then the application gets this data
and notify the transport layer (TCP in this case) that data can be ACK.
At this point the TCP layer can do two things:
1. ACK the data
2. Wait for 200 ms to see if applications has to sent more data to the
other host, so ACK and new data will be sent together, saving bandwidth.

Delay ACK is enable by default on most of the tcpip stack
implementations and it can be turn on or off at two places:

>>> there are some major side effects when turn it ON ?? you do not want to enable delayed ACK for real time apps e.g. telnet or rlogin. These apps expect you to send the data as soon as the keystroke has been types, and not wait for 200ms to see if there??s more data to do.

1. Transport layer (TCP) ?? when set here, it applies to all applications
2. Application layer (applications you are using). ?? this is through APIs that application developers can take advantage of. Normal administrators will not have the option to disable this, unless the developers explicitly give users the option.

When you use the first one, this option will be applied to all services
running on this server and using TCP as transport layer.
Some applications want the data to be immediately ACK so they can move
it receiving windows (called windowing) faster and another applications
have no problems waiting for 200 ms for the ACK. In you case, the
application does care about it and just turning off this feature at TCP
layer helps.
This feature can also be turned off at application layer, so when the
application loads and register itself with TCP, it communicate that it
does want to disable delay ACK, so TCP layer will only turn it off for
this application and not for the rest of the services.

2. < <
We discovered a problem with bm proxy and certain web sites that they do
not like the delay ACK. At the point we found it, there was no way to
turn it off at application layer, so we have to use the "general" TCP
setting. Latest proxy.nlm have turn off this feature at application
layer by default.
rick jones
Honored Contributor

Re: TCP/IP settings.

99 times out of 10, if disabling delayed ACK's speeds-up an application, it suggests that the application is broken. Likely as not it is sending logically associated data in separate calls to send() and that is not good. We could confirm this with a packet trace from tcpdump. I would guess that it shows the application making small (< MSS) related sends into the network.

Indeed, delayed ACKs help for low-bandwidth links, but they also help with CPU consumption. An ACK is basically just as "expensive" as a data segment in terms of CPU cycles consumed.

There is no way to enable immediate ACKs with the HP-UX networking stack. One can (but really should not need to for properly behaving applications) decrease the delayed ACK timer with ndd.

The HP-UX 11 stack has another algorithm in it to avoid sending ACKs that will back-off the ACKs to even fewer than ACK-every-other. The bounds are controlled by another ndd tunable - tcp_deferred_ack_max. The lower limit is 2, not one (hence no way to disable delayed ACKs) there have been rare occasions where _when there is lots of packet loss_ dropping this value helps. However, if there is not packet loss, there should be no need to change that setting, and probably not even if there is packet loss. The algorithm detects that and adjusts accordingly.
there is no rest for the wicked yet the virtuous have no pillows
Leif Halvarsson_2
Honored Contributor

Re: TCP/IP settings.

Thank you for your reply. As I wrote I have some strange performance problem when backing up a Compaq DL 380 NetWare 6 server with Data Protector. Setting TCP DELAYED ACKNOWLEDGEMENT = OFF helps but don't solve the problem completly. My idea was that this setting caused some mismatch with the settings on the HP-UX server.
As it seems this is not the case. When trying the same backup on a Fujitsu server with an identical NetWare installation I have the same problem (very bad performance) if TCP DELAYED ACKNOWLEDGEMENT = ON but normal performance if set to OFF.

Perhaps my problem with the Compaq server is hardware related (NetWare 6 and Compaq DL 380)

rick jones
Honored Contributor

Re: TCP/IP settings.

typically, it is the system being backed-up that is sending the data, and so is generally not sending much in the way of ACKs. that being the case, I would not at first expect enabling or disabling delayed ACKs on the backup client to have much of an effect.

now, if there is some non-trivial exchange from the backup _server_ (the UX system) to the backup client (the netware boxes) then enabling/disabling the delayed ACKs on the netware boxes might have an effect.

the best thing to do here is to get a packet trace of a backup from one of the systems to the server (I myself prefer tcpdump traces :) and then we can see the actual traffic.
there is no rest for the wicked yet the virtuous have no pillows