HP-UX TCP/IP Performance White Paper, March 2008

6144 retransmit timeouts

This is the number of times TCP's retransmission timer has expired on a connection or connections. When

this timer expires a TCP segment will be retransmitted. In general, the Retransmission Timeout (RTO)

estimator in HP-UX 11i is rather robust, which means the only time there would be spurious timeouts would

be when someone has "tuned" tcp_rexmit_interval_* to bogus values. In cases where the network

has a highly variable RTT one might want to set the ndd tunable tcp_smoothed_rtt to a value of one to

select an even more robust RTO estimator.

If the number of retransmit timeouts is larger than the number of data segments retransmitted, it implies that

SYN segments are being retransmitted and the system is having trouble getting connections established. It

could be that the remote system(s) have full listen queues and are discarding the SYN segments. It could

also be that standalone FIN segments are being retransmitted.

If the number of retransmit timeouts is smaller than the number of data segments retransmitted, it implies the

difference between the two is roughly the number of "fast retransmissions" sent by this system.

459 connections dropped by rexmit timeout

This is the number of connections where the total time a given segment has remained unACKed has

exceeded the value of tcp_ip_abort_interval. It means that either the remote system or network died

or was overloaded, or someone has tuned tcp_ip_abort_interval to too small a value.

66 persist timeouts

This is the number of times the persist timer has expired on one or more TCP connections. When the persist

timer expires a zero-window probe is sent to help "remind" the remote TCP that we are anxiously awaiting

a window update.

32590 keepalive timeouts

27598 keepalive probes sent

11 connections dropped by keepalive

If an application sets SO_KEEPALIVE with setsockopt(), and the connection has been idle (no data flow

either way) for tcp_keepalive_interval milliseconds (default two hours) the TCP stack will have a

keepalive timeout and may then send TCP keepalive probes to make sure the remote TCP is "still there."

The keepalive mechanism will be enabled for any connection, regardless of the setting of SO_KEEPALIVE,

once the application calls close() against the socket. In this case, keepalive probes will be sent after

tcp_keepalive_detached_interval milliseconds.

In either case, if the keepalive probe does not elicit a response from the remote within

tcp_ip_abort_interval, the connection will be dropped (aborted) with a RST segment just as if it had

been dropped by retransmission timeout.

0 connect requests dropped due to full queue

If the number of connection requests (SYN segments) dropped due to full queue is non-zero it means that

either the setting for tcp_conn_request_max is too small, or one or more applications on the system is

using too small a value for the listen backlog in its call to listen().