Hi !!!!

we have SunOS av2s043p 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Fire-280R .
When I look in the output of the netstat -sP tcp retransmission on the byte level is too big, but if you look at the retransmission on the package level it looks ok.

Here is the whole output of the netstat -sP

TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400
tcpRtoMax = 60000 tcpMaxConn = -1
tcpActiveOpens =1499528 tcpPassiveOpens =8767828
tcpAttemptFails = 18850 tcpEstabResets =456046
tcpCurrEstab = 29 tcpOutSegs =279464133
tcpOutDataSegs =249137805 tcpOutDataBytes =2824453618
tcpRetransSegs =5925866 tcpRetransBytes =2883561798
tcpOutAck =30295265 tcpOutAckDelayed =3857090
tcpOutUrg = 0 tcpOutWinUpdate = 0
tcpOutWinProbe = 16708 tcpOutControl =20687100
tcpOutRsts = 61846 tcpOutFastRetrans =424669
tcpInSegs =213950645
tcpInAckSegs =141992532 tcpInAckBytes =2284068601
tcpInDupAck =12324728 tcpInAckUnsent = 0
tcpInInorderSegs =34809828 tcpInInorderBytes =582918467
tcpInUnorderSegs = 1332 tcpInUnorderBytes =1022232
tcpInDupSegs =415088 tcpInDupBytes =25296209
tcpInPartDupSegs = 20 tcpInPartDupBytes = 7622
tcpInPastWinSegs = 22 tcpInPastWinBytes =3105517874
tcpInWinProbe = 0 tcpInWinUpdate = 9834
tcpInClosed = 28635 tcpRttNoUpdate =3590912
tcpRttUpdate =135306923 tcpTimRetrans =7167431
tcpTimRetransDrop = 50555 tcpTimKeepalive = 16037
tcpTimKeepaliveProbe= 10329 tcpTimKeepaliveDrop = 879
tcpListenDrop = 18 tcpListenDropQ0 = 0
tcpHalfOpenDrop = 0 tcpOutSackRetrans =1238553

mtu on our network interfaces is set to mtu=1500.

if you calculate retransmission on the byte level:
(tcpRetransBytes=2883561798) /(tcpOutDataBytes=2824453618) =
1.02 *100 = 102 % retransmission. This is terrible.

on the segments level:
(tcpRetransSegs=5925866)/(tcpOutDataSegs=249137805)= 0.023 *100 = 2% This look Ok.

What I don't understand is this:
during 3-way-handshake maximum segment size is negotiated (it is belowe 1500 bytes), TCP level will create segments in this size to fill the receving window from client.
Segment are transmited and if they don't come to the destination or ACK from client doesn't come back package or packages will be retransmitted (in my case I don't have package retransmission).
Question is still from where do I get this bytes retransmission, is it possible that TCP repackage rest of the bytes ( which are still waiting to be transmitted in the retransmission queue) to fit in the new window size in completely new packages ??

Maybe that is reason why average bytes/segment size is very low (more packages for same bytes)

(tcpOutDataBytes=2824453618)/(tcpOutDataSegs=249137805) = 11 bytes/ segment

(tcpRetransBytes=2883561798)/(tcpRetransSegs =5925866) = 487 bytes/retransmitted segment

Does someone knows when TCP will repackage data in the retransmission queue and are this new packages completely new so when they are transmitted TCP counts them as a new ones ????

cheers

If somebody is interested in reason for difference on retransmission between package and byte level.

Difference is because of the 32 bit counter which counts transmitted byte ( tcpOutDataBytes ).

As our user downloads lots of files this counter is overflowed and it starts to count from begining. In the same time as retransmission is not so big tcpRetransBytes 32 bit counter counts retransmitted bytes from the same position where it was ( he doesn't know that tcpOutDataBytes has overflowed ).

so the way to calculate retransmission like this

( tcpRetransBytes / tcpOutDataBytes ) *100

is wrong.

The correct way should be:

start netstat -sP tcp command in some intervals (e.g every hour)
calculate difference between same counters

e.g
tcpRetransBytes1 - tcpRetransBytes2 = tcpRetransBytesDelta
tcpOutDataBytes1 - tcpOutDataBytes2 = tcpOutDataBytesDelta


and then calculate retransmission on byte level

( tcpRetransBytesDelta / tcpOutDataBytesDelta ) *100

given value will be similar to the retransmission on package level.

Well I needed 4 month to find that nothing is wrong with my system

cheers, Dara