TCP settings in HP

[YLTan]

I need to chg two tcp parameters.

how to chg tcp_ip_abort_interval and tcp_keepalive_interval for HPUX11.11? Does it reflect to all interfaces both 100Mbps and Gigabit?

What does this two parameters do?

[Michael Tully]

I am fairly sure interface types are affected.

# ndd -h supported
# ndd -h tcp_ip_abort_interval
# ndd -h tcp_keepalive_interval

[Rajeev Shukla · Accepted solution]

Hi You can get the description of both these parameters from
ndd -h
have a look at man pages of ndd also changing this parameter would effect all the interfaces.

To permanently set these parameters edit /etc/rc.config.d/nddconf

[rick jones]

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

Any particular reason you feel you need to alter those parameters?

Ndd settings for TCP will affect _all_ TCP communications, regardless of interface.

[YLTan]

we have iplanet webserver error logs saying insufficient resources with oserr=233. someone do an investigation and mentioned that beside increasing the buffercache we may also need to tune these to parameters
to 60000 and 900000 respectively.

Do you think it will help?

[rick jones]

well, the 233 from iplanet means that iplanet isn't getting around to calling accept() quickly enough. altering the tcp_ip_abort_interval and the keepalive interval is unlikely (in my opinion) to make iplanet get around to calling accept faster.

what they will affect (possibly) is how many file descriptors iplanet is tracking at any one time. shortening those settings may cause TCP to cull connections more quickly - and perhaps cull some otherwise good connections.

to get an idea of whether or not iplanet is indeed being hampered by "decaying" connections, you might look at the output of netstat -p tcp and see how many, if any, connections are being dropped by rexmit timeout. compare that to the totcal number of connections and such. that will tell you how many connections are being closed by reaching tcp_ip_abort_interval - either during normal data transfer, or after tcp_keepalive_interval has been reached. what it will not include will be those ocnnections aborted because the system received a RST in response to a keepalive probe.

another way to go about it would be to run tusc against one or more of the iplanet processes, have tusc only trace the socket and close system calls, and have it include timestamps. you can then do a bit of scripting to measure how long connections remain open and see the distribution. if you are going to include connections dropped by keepalive and such, the tusc trace will need to be rather longer than tcp_keepalive_interval+tcp_ip_abort_interval.

whether or not you have sufficient CPU to permit that I have no idea - that will have to be your call.

[YLTan]

thanks Rick for the advice, I will investigate further.