This post explains you the information on the TCP retransmission measurement usi ng netstat -s for Solaris.

A system with a high retransmission rate indicates network congestion and can ca use network oriented applications (like web servers) to operate slowly. Procedure to Calculate TCP retransmission rate: TCP expects acknowledgments from the destination system when it successfully rec eives segments from the sender. If it does not receive the acknowledgment within a certain time, it will retransmit the segment. To implement this scheme of retransmission, TCP starts a timer for each packet transmitted. Unless the acknowledgment is received before this timer expires, T CP will assume that the packet is lost and will retransmit the packet. The rate at which packets are retransmitted is called the retransmission rate , and is an i ndicator of network health. To calculate the retransmission rate, use the output of the and. We need the values for the counters tcpOutDataBytes tcpRetransBytes tcpOutDataSegs tcpRetransSegs. netstat -s -P tcp comm

The retranmission rate is given either in terms of bytes or segments. To calcula te the byte retransmission rate: %retrans = ( tcpRetransBytes / tcpOutDataBytes ) * 100 To calculate the segments retransmission rate: %retrans = ( tcpRetransSegs / tcpOutDataSegs ) * 100 As a rule of thumb, retransmission rates over 10% can indicate degraded networ k performance on a LAN. The internet may vary between 10 and 20 percent dependi ng upon traffic conditions. In some environments, delaying the retransmission t o accommodate slower networks may be needed. General Retransmission Rules: moderate retransmissions < 10% warning > 15% ( > 2/sec ) excessive retransmissions > 25% action required > 40% High rates (greater than 30%) may be relieved by adjusting the tcp_rexmit_interv al* timers in Solaris. Some of the reasons for a high retransmission rate are: Congested network, packets dropped. This is the most common cause. Bad network hardware. Check netstat -i output for collisions or errors, also chec k the various network components involved. Missing or out of date TCP or IP patches. Incorrectly tuned TCP parameters (tcp_rexmit_interval_min,tcp_rexmit_interval_m ax, tcp_rexmit_interval_initial, tcp_ip_abort_interval). Clients accessing server have slow or error-prone connections.

Notes: Be aware that these counters are 32 bits, and on a system with a high net work load. They can experience an overflow and result in rates over 100%. In tho se cases, monitoring the system (with the command netstat -s ) at periodical interv als or after the next downtime would be the recommended action to differentiate between a system with a high network load and a real retransmission problem. The most acurate way to get the correct rate is by taking the values twice and u sing the deltas of each counter.