Question : Solaris 2.6 TCP-send/receive-Buffers

I am currently running Solaris 2.6 with the default 8K TCP-send/receive-Buffers and thinking to use ndd to set it 64k for a high output application. Does anyone know how to read the nestat output to see the   TCP-send/receive-Buffers especially what the Swind, Send-Q, Rwind, and Recv-Q numbers represent or maybe suggest other utilities to monitor it.?

Example out output file.

Local Address        Remote Address     Swind  Send-Q
qatest                feedtest.test.com  64833  0

Rwind Recv-Q  State
2271     327   ESTABLISHED


Thanks,

-VT

Answer : Solaris 2.6 TCP-send/receive-Buffers

The window size is used in the TCP protocol to indicate how much space the is available for data reception. If I advertise a large window to you, I am giving you permission to send me lots of data. Conversely, if my receive buffer is nearly full, I will advertise a small window to you. Swind is the window size at the remote end; Rwind is the window size at the local end.

The queue size is how much data is waiting to be sent. Send-Q is the amount of data that the application has written and the local host is waiting to be transmit; Recv-Q is the amount of data received but not yet read by the application.

In the example above, we would send the other end a lot of data if we wanted to, but no data is pending. We don't have a lot of space for receiving more data. If we were to call read() right now, we would get 327 bytes.

Setting a large output buffer will mean that your application doesn't have to do lots of kernel/user-space transitions in order to keep the transmitter busy. You probably want a large receive buffer on the remote end for the same reason. Note that the overheads go up when the receive buffer fills up, so make sure the remote end reads as fast as it can. If one of the windows falls to zero, you've got a performance problem in your reading application which will cause the sending application to stall.

Many protocols fail not because of lack of bandwidth but because of pipeline stalls, ie. the protocol requires that the sender gets an acknowledgement from the remote end before sending more data. It is essential that streaming is considered in your protocol design. This is much more important than buffer sizes.