1 2 next »

1. Rate adjustments, Maturation
2. In brief, Minor gems

Kernel Log: Coming in 3.2 (Part 1) - Networking

by Thorsten Leemhuis

The TCP stack is now faster at adapting the data transmission rate to the available line capacity. The drivers for Wi-Fi components by Atheros and Broadcom have matured considerably; other drivers will support more LAN and Wi-Fi hardware in 3.2 than they did before.

No major changes have been integrated into the main development branch of Linux since the first release candidate of Linux 3.2 became available, closing this version's merge window. Linus Torvalds will probably soon release the second RC of this kernel version, the final release of which is expected to become available in mid to late January; until then, Torvalds will mainly incorporate fixes and small, harmless improvements as he has done in the past few days.

The Kernel Log is now in a position to provide a comprehensive overview of the most important new features of Linux 3.2. As usual, this information will be presented within the "Coming in 3.2" series of articles that will gradually cover the kernel's various functional areas. Part 1 of the series is below and describes the most important changes to the network stack, and the related LAN and Wi-Fi hardware drivers. Over the coming weeks, further articles will discuss the kernel's storage support, filesystems, architecture code, infrastructure, and other hardware drivers.

Rate adjustments

The kernel developers have extended the TCP stack of Linux 3.2 to provide "Proportional Rate Reduction" (PRR) support. Introduced by a Google employee and described in an IETF draft, this algorithm is designed to adapt transmission rates to the rates that can be processed by the recipient and by the routers along the way; especially after reducing the rate to prevent an imminent overload, the algorithm is designed to return to the maximum transfer rate faster than the previously used method, which is described in RFC 3517 ("A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP").

According to the developer's measurement results, the algorithm's faster transfer rates reduce HTTP response times by three to ten per cent. The functional details are available in the commit comment, in an article on LWN.net, in a paper on the subject, and in two PDF documents of IETF presentations (1, 2).

Maturation process

In the sometimes slightly muddled situation involving two drivers for recent Broadcom Wi-Fi chips, the Brcmsmac and Brcmfmac Brcm80211 drivers developed by Broadcom itself have now won the race and made it into the network subsystem. Released more than a year ago, the driver code was previously kept in the staging area, which is the area for code that doesn't meet the developers', or the kernel hackers', quality requirements; some distributions omit staging drivers for this reason. Over the past year, the Broadcom developers have fixed most of the drivers' deficiencies, aided by experienced kernel developers. The B43 driver that has been part of the kernel for quite some time and which also supports older Wi-Fi chips by Broadcom will, for the time being, continue to support some of the Wi-Fi components that are also covered by Brcm80211, although the kernel will probably give preference to the latter in the long term. However, those who want to use the Brcm80211 drivers are currently unable to configure the Bcma driver, which is required by B43 to access some of Broadcom's recent Wi-Fi components.

The network subsystem now also includes the Ath6kl Wi-Fi driver for Atheros' AR6003 component. It is based on the identically named staging driver that was removed at the same time. The improved and significantly smaller version of the driver was developed outside of the staging area; it is much reduced in size, and the commit comment states that it does not offer all the functions that were available with the staging driver.

The extensive clean-up measures related to these two drivers, and the drivers' relocation, are partially responsible for the large number of new and removed lines of source code shown in a diffstat for Linux 3.2. The high diffstat figures were also caused by the Rtl8192e Wi-Fi driver in the staging area being replaced by a thoroughly revised code variant that stands a much better chance of eventually being moved from the staging area to the network subsystem, although it still requires attention (for example 1, 2, 3).

Next: In brief, Minor gems

1 2 next »