Talk:Tuning TCP

From Gentoo Linux Wiki

(Redirected from Talk:HOWTO TCP Tuning)
Jump to: navigation, search

[edit] Interactivity

[edit] Suggestion

In the "Transmit Buffer" section, it says: "There is little harm in increasing the size of your transmission buffer..."

What about interactivity, eg ssh, etc? Having a lot of packets queued up to be transmitted effectively kills low-latency connections.

Using QOS (eg wondershaper, etc) via iptables can help here. But, I don't think having a large transmit buffer is good.

[edit] Response

While I haven't hacked the TCP implementation in the kernel, I don't think that this is the case. The two send-related settings that are altered are net.core.wmem_max and net.ipv4.tcp_wmem.

net.core.wmem_max sets the maximum size of any socket's buffers, but does not actually change any socket. A program would have to request an unusually large SO_SNDBUF socket option.

net.ipv4.tcp_wmem sets the minimum, default, and maximum sizes of TCP send windows. The minimum value suggested is 4k, the same as the default minimum setting. The default value suggested, 65536 is a significant increase over the default default value (hehe) of 16384. The other difference is the maximum, which is increased to the same value as the socket maximum.

One must remember that the window size is the amount of send buffering, not send queuing. It is the maximum amount of data that can be sent without an acknowledgment from the receiver(therefore, it may need to be re-transmitted). It is not an amount of data to be queued before packets are sent. Packets will only be queued if the receiver advertises a smaller receive window,indicating that they are unable to receive at the rate the sender is transmitting. In any case, packets are sent immediately when the receiver is capable of receiving them (as indicated by a non-zero window size in the TCP header). Interactive application protocols should not be affected at all by the suggested settings, only high-bandwidth transfers, and only positively if the computer has sufficient memory.

In summary, I don't think the changes suggested will cause any packet queuing at all, and therefore should not degrade performance of highly interactive applications. Can anyone confirm/refute my analysis?

--AlecTavi 13:55, 1 August 2007 (UTC)

Personal tools