what's ndd's parameter for "tcp_maxretrans" supported by nettune

[Gary Yu]

Dear all,

We are having some problems with OBII, by searching the forum and knowldge base(http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=576355), I found a solution to set a NT registry value based on a nettune parameter tcp_maxretrans. But on HPUX 11.0, I can't find such parameter with ndd, does anyone know the corresponding parameter for tcp_maxretrans?

thanks,
Gary

[harry d brown jr]

Maybe this will help?

ndd -h | grep xmit |tr -s " " ""|sed "s/^ //"|cut -d" " -f1|xargs -i ndd -h {}



tcp_rexmit_interval_initial:

Initial value for round trip time-out, from which the retransmit time-out is computed. [1,20000] Default: 500ms


tcp_rexmit_interval_initial_lnp:

Same as tcp_rexmit_interval_initial, but used for devices with the LNP (Long Narrow Pipe) flag set. [1,20000] Default: 1500 (1.5 seconds)


tcp_rexmit_interval_max:

Upper limit for computed round trip time-out. [1,7200000] Default: 60000 (1 minute)


tcp_rexmit_interval_min:

Lower limit for computed round trip time-out.

Unless you know that all TCP connections from the system are going through links where the RTT is greater than 500 milliseconds, and are also _highly_ variable in their RTTs you should not increase this value. If you increase this value, and there are actual packet losses, you could have a drop in throughput as TCP could sit longer waiting for a TCP retransmission timer to expire. Similarly, unless you have concrete proof that the RTT is never more than 500 milliseconds, you should not decrease this value as it could result in spurious TCP retransmissions which could also decrease throughput by keeping the TCP congestion window artificially small. [1,7200000] Default: 500ms


tcp_xmit_hiwater_def:

The amount of unsent data that triggers write-side flow control. [4096,-] Default: 32768 bytes


tcp_xmit_hiwater_lfp:

The amount of unsent data that triggers write-side flow control for fast links.[4096,-] Default: 65536 bytes


tcp_xmit_hiwater_lnp:

The amount of unsent data that triggers write-side flow control for slow links.[4096,-] Default: 8192 bytes


tcp_xmit_hiwater_max:

Limits the send buffer size for TCP sockets or communication endpoints specified in a SO_SNDBUF option of a setsockopt() call or XTI_SNDBUF option in a t_optmgmt() call.

A setsockopt() call with a SO_SNDBUF option that exceeds the corresponding kernel parameter value will fail and return the errno value EINVAL.

A t_optmgmt() call with an XTI_SNDBUF option that exceeds the corresponding kernel parameter value will fail and return the t_errno value TBADOPT.
[1-2147483647] Default: 2147483647 bytes


tcp_xmit_lowater_def:

The amount of unsent data that relieves write-side flow control.
[2048,-] Default: 8192 bytes


tcp_xmit_lowater_lfp:

The amount of unsent data that triggers write-side flow control
for fast links.[4096,-] Default: 65536 bytes


tcp_xmit_lowater_lnp:

The amount of unsent data that triggers write-side flow control
for slow links.[4096,-] Default: 8192 bytes

#

live free or die
harry

[Gary Yu]

thanks Harry for the reply, but HP's document (http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000066945101) said this parameter is a "counter" not a "timer", so I would assume it's not for timeout settings...

thanks,
Gary

[rick jones · Accepted solution]

TCP in 11.0 and later no longer counts retransmissions, it tracks how long a segment has remained unacknowledged. As such, there is no 1 for 1 replacement fot tcp_maxretrans on 10.20. The tcp_ip_abort_interval is the setting that controls how long TCP will wait for an ACKnowledgement of a segment it has sent, and the number of times it has been able to retransmit that segment will depend on the tcp_rexmit_interval_min and tcp_rexmit_interval_max.

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

I'm a triffle confused though - the thread you list talks about (presumeably) "NT" giving-up too soon on a TCP connection. The HP-UX retrans values wouldn't really come into play there.

[Gary Yu]

thanks Rick for the clarification. yes indeed the issue here is NT give up too soon, and the solution for this, based on some previous threads, is to set a registray entry on the NT server, the value for this registray entry should be in line with tcp_maxretrans on the HP server(cell manager)

thanks,
Gary