Daniel Micay 45b8e80e31 switch congestion control back to BBRv1 from CUBIC ... BBRv1 provides much better throughput in many cases and is particularly useful for our update servers. The fairness issues based on round trip time are not a major issue for us. The fairness issues for competing with traditional loss-based congestion control are relevant to us but it seems to benefit it more than it hurts us. BBRv3 will fix most of this while preserving nearly all the benefits and will likely be shipped as a replacement for BBRv1 in the Linux kernel rather than another option. The reason we rolled it back last time was seeing cases of the initial bandwidth estimate being overly low combined with a very bad interaction with synproxy causing low bandwidth initially. We've partially addressed the synproxy issue by raising the synproxy threshold based on conntrack table size which we're now fully scaling based on available memory. If we decide this is still a significant issue, we can limit using BBRv1 to our update servers where it has massive benefits and the least downside due to initial bandwidth not being as important. BBRv3 will help with this by probing Round Trip Time every 5 seconds instead of 10 seconds but still has similar issues.		2025-07-01 10:13:05 -04:00
..
local.conf	switch congestion control back to BBRv1 from CUBIC	2025-07-01 10:13:05 -04:00
metal.conf	raise RAID resync limit for bare metal servers	2025-04-23 21:10:49 -04:00