2.6.27 default TCP congestion control regression...

Confirmed that this is still the default in linux-image-2.6.27-6-generic-2.6.27-6.9 and that the default config for the upstream kernel is "cubic".

I do note that 2.6.24 in hardy/8.04 was still using "reno" by default, so this wouldn't be a potential regression in Intrepid.

What can I do to expedite this change?

This is crucial particularly for high bandwidth links, which are have a higher latency-bandwidth ratio (eg xDSL, 10gigE), and particularly networks where some loss is expected (eg internet, wireless LAN).

Hi Daniel,

I can bring this to the attention of the Ubuntu kernel team. However, with it being less than a week away from the Intrepid kernel freeze, I'm uncertain of the likelyhood of this getting resolved prior to Intrepid final and may have to wait for Jaunty.

While "cubic" may be the upstream default, its unlikely that it'll change from "reno " this close to release. Instead, you can change it at runtime, e.g.,

sudo su -
modprobe tcp_cubic
echo > cubic /proc/sys/net/ipv4/tcp_congestion_control
exit

Yes, it can easily changed at runtime, but this is not the usage bug we have.

All the users of Ubuntu Intrepid will get penalised by the poor scaling and unfairness of TCP Reno (using blind congestion control [1]), which is why TCP cubic was introduced and became default in 2.6.19, some 2 years ago; all the high-profile distros are sure to enable this per default, since TCP Reno suffers in particular use patterns, such as wireless (ie lossy net) throughput, fairness on congested networks (eg xDSL), throughput on high BDP networks (eg internet), plus it'll get worse as the bandwidth product of xDSL lines increased, but latency doesn't decrease (due to c).

I want people using Intrepid to be able to achieve the best experience on Ubuntu, not have to move to SuSE or Redhat, or publish benchmarks showing penalties on Ubuntu (eg from Phoronix), but perhaps we have to wait another 6 months again?

--- [1]

http://www.powerset.com/explore/semhtml/Taxonomy_of_congestion_control?query=CUBIC+TCP

This bug was fixed in the package linux - 2.6.27-7.11

---------------
linux (2.6.27-7.11) intrepid; urgency=low

  [ Amit Kucheria ]

  * STABLE queue: mac80211: fix two issues in debugfs
    - LP: #275227
  * SAUCE: Adds support for COMPAL JHL90 webcam

  [ Ben Collins ]

  * SAUCE: (no-up) x86: Quiet "Kernel alive" messages
    - LP: #39985
  * SAUCE: (no-up) Modularize vesafb
  * build/config: Enable vesafb module
  * build: Switch to vesafb as preferred.

  [ Leann Ogasawara ]

  * Add Dell Dimension 9200 reboot quirk
    - LP: #271370

  [ Michael Haas ]

  * SAUCE: Revert aufs changes from AppArmor merge

  [ Tim Gardner ]

  * fix virtio udeb layout
    - LP: #257739
  * Enabled CONFIG_EXT4DEV_FS=m
  * Changed default TCP congestion algorithm to 'cubic'
    - LP: #278801
  * SAUCE: ipw2200: change default policy for auto-associate
    - LP: #264104

  [ Upstream Kernel Changes ]

  * x86, early_ioremap: fix fencepost error
    - LP: #263543

 -- Tim Gardner <email address hidden> Sat, 11 Oct 2008 08:07:42 -0600

This bug was fixed in the package linux-lpia - 2.6.27-4.9

---------------
linux-lpia (2.6.27-4.9) intrepid; urgency=low

  [ Amit Kucheria ]

  * SAUCE: Start new release Ignore: yes
  * SAUCE: Add LPIA keyword in front of all our tags
  * SAUCE: Disable DYANMIC_FTRACE
    - LP: #263555
  * SAUCE: Disable ath5k from configs
    - LP: #288148
  * SAUCE: Fix rebase script some more
  * SAUCE: Change default TCP congestion algorithm to cubic
    - LP: #278801
  * SAUCE: Enable vesafb module

 -- Amit Kucheria <email address hidden> Thu, 23 Oct 2008 20:07:26 +0000

The i386 and PowerPC Intrepid ports kernels also need to be updated to use cubic:

$ git grep DEFAULT_TCP_CONG
config/hppa/config:CONFIG_DEFAULT_TCP_CONG="cubic"
config/i386/config:CONFIG_DEFAULT_TCP_CONG="reno"
config/ia64/config:CONFIG_DEFAULT_TCP_CONG="cubic"
config/powerpc/config:CONFIG_DEFAULT_TCP_CONG="reno"
config/sparc/config:CONFIG_DEFAULT_TCP_CONG="cubic"

Is this something that could go out in a ports SRU post Intrepid release, or would we have to wait for Jaunty?

Fix committed to the ubuntu-ports-jaunty branch. We can SRU the ports kernel for this as well.

Is there any performance test that compares reno to cubic?

You can use iperf and many other related. It's a question of testing high BDP and lossy, eg wireless networks, especially with multiple flows. There probably are a lot of tests already out there.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

This bug was fixed in the package linux-ports - 2.6.28-1.1

---------------
linux-ports (2.6.28-1.1) jaunty; urgency=low

  [ Luke Yelavich ]

  * SAUCE: Add rebase-ports and retag-ports scripts based on the scripts
    used for the lpia kernel
  * Remove build depends on gcc 4.1 for powerpc and ia64
    - LP: #297152
  * Enable CONFIG_PPC_PASEMI on powerpc64-smp
    - LP: #213668
  * Add the fec_mpc52xx network driver to the nic-modules udeb
    - LP: #201346
  * Changed default TCP congestion algorithm to 'cubic' on i386 and powerpc
    - LP: #278801
  * Enable ALSA subsystem and drivers for i386
    - LP: #308058
  * Turn off abi/module checks for hppa, ia64, and sparc
  * linux-headers packages should depend on, and be symlinked against
    linux-ports-headers
    - LP: #291487

 -- Luke Yelavich <email address hidden> Sat, 07 Feb 2009 03:27:42 +1100

Since 8.04 is termed LTS and what a lot of people use for server OS, can someone please backport this to Heron?

I hate workarounds, but until this is changed (not my decision, but a difficult/policy one), this is handy:

echo 'echo cubic >/proc/sys/net/ipv4/tcp_congestion_control' >>/etc/rc.local

Actually, since the module is not loaded by default, I ended up putting tcp_cubic in /etc/modules and adding an entry to /etc/sysctl.conf

Seems to work.