<story><title>Linux network performance parameters</title><url>https://github.com/leandromoreira/linux-network-performance-parameters</url></story><parent_chain></parent_chain><comment><author>klabb3</author><text>A random thing I ran into with the defaults (Ubuntu Linux):&lt;p&gt;- net.ipv4.tcp_rmem ~ 6MB&lt;p&gt;- net.core.rmem_max ~ 1MB&lt;p&gt;So.. the tcp_rmem value overrides by default, meaning that the TCP receive window for a vanilla TCP socket actually goes up to 6MB if needed (in reality - 3MB because of the halving, but let&amp;#x27;s ignore that for now since it&amp;#x27;s a constant).&lt;p&gt;But if I &amp;quot;setsockopt SO_RCVBUF&amp;quot; in a user-space application, I&amp;#x27;m actually capped at a maximum 1MB, even though I already have 6MB. If I try to &lt;i&gt;reduce it&lt;/i&gt; from 6MB to e.g. 4MB, it will result in 1MB. This seems very strange. (Perhaps I&amp;#x27;m holding it wrong?)&lt;p&gt;(Same applies to SO_SNDBUF&amp;#x2F;wmem...)&lt;p&gt;To me, it seems like Linux is confused about the precedence order of these options. Why not have core.rmem_max be larger and the authoritative directive? Is there some historical reason for this?</text></comment>
<story><title>Linux network performance parameters</title><url>https://github.com/leandromoreira/linux-network-performance-parameters</url></story><parent_chain></parent_chain><comment><author>napkin</author><text>Just changing Linux&amp;#x27;s default congestion control (net.ipv4.tcp_congestion_control) to &amp;#x27;bbr&amp;#x27; can make a _huge_ difference in some scenarios, I guess over distances with sporadic packet loss and jitter, and encapsulation.&lt;p&gt;Over the last year, I was troubleshooting issues with the following connection flow:&lt;p&gt;client host &amp;lt;-- HTTP --&amp;gt; reverse proxy host &amp;lt;-- HTTP over Wireguard --&amp;gt; service host&lt;p&gt;On average, I could not get better than 20% theoretical max throughput. Also, connections tended to slow to a crawl over time. I had hacky solutions like forcing connections to close frequently. Finally switching congestion control to &amp;#x27;bbr&amp;#x27; gives close to theoretical max throughput and reliable connections.&lt;p&gt;I don&amp;#x27;t really understand enough about TCP to understand why it works. The change needed to be made on both sides of Wireguard.</text></comment>