Though the open source FreeBSD operating system has changed in many aspects over the last 16 years of its life, one item that has remained relatively static is its underlying network routing architecture.
No more: It's getting an overhaul with the upcoming FreeBSD 8.0 release.
FreeBSD 8.0, due out next month, will include a new routing architecture that takes advantage of parallel processing capabilities. According to its developers, the update will provide FreeBSD 8.0 with a faster more advanced routing architecture than the legacy architecture.
It's an important change for FreeBSD, which has emerged as a key open source operating system for networking vendors, with players like Juniper, Coyote Point, Blue Coat and others offering their own network operating systems that are based on FreeBSD.
The new routing architecture was written Qing Li, senior architect at Blue Coat, as a way to give back to the open source community.
"Blue Coat's ProxySG networking kernel was partially derived from the FreeBSD kernel," Li told InternetNews.com. "Blue Coat is a sponsor of my open source development work, so this is a good way to contribute to the open source community."
Blue Coat's ProxySG is a WAN optimization device that relies on network intelligence to accelerate traffic.
The new routing architecture in FreeBSD 8 is also about optimization, as it reduces data dependencies across networking layers. The end result is a routing architecture that can take better advantage of multi-core, parallel processing CPUs.
"The new routing technology works on both multi-core as well as single-core CPUs," Li said. "The performance gain is most visible in the multi-core situation, though."
But making changes also has important implications for BSD 8.0, since a key goal of the release is about ensuring a degree of compatibility with prior releases and the existing software ecosystem.
"Since the rewrite affects fundamental packet processing and the operation of protocols within the networking kernel, I had to ensure regression risk was low and compatibility was high," Li said. "For example, those applications that are part of the ports, which interact with the kernel (e.g. retrieving the routing information, waiting for notification about routing table changes ) will continue to compile and operate semantically correct."
In a technical paper that Li is publishing and talking about today at a conference in Spain, Li explained that the legacy version of the FreeBSD routing architecture actually reduced parallelism on SMP (define) and parallel architectures.
"As a result of the dependency between L2 and L3 (define), the processing through these two layers was single-threaded," Li wrote in his paper. "A common parallel TCP/IP protocol stack design is to allow L2 and higher layer processing to run independently of each other, having each processor managing different protocols. The aforementioned locking contention increased processor stalling and prevented one from benefiting from more advanced hardware platforms."
According to Li, contention locks consumed as much as 47 percent of a CPU's time with the legacy routing architecture, determined through a test with eight transmitting threads.
"With the new split L2/L3 design, the L2 and L3 references can be cached in the protocol control block for connected sockets or in a flow table for unconnected sockets and forwarding," Li wrote. "Thus we see that very little of the CPU time is now spent in the locking primitives even when there are [eight] transmitting threads."
But what is it called?
While many operating system vendors will tend to brand new or improved technology with interesting names, that's not the case with the new routing architecture in FreeBSD 8.0.
"No, there is no catchy name," Li told InternetNews.com. "On the mailing list, I typically referred to it as 'L2/L3 rewrite' [and] 'new ARP/ND6 rewrite' when answering questions and providing patches."
Sun Microsystems, in contrast, recently pushed out a new networking architecture called Project Crossbow, for its openSolaris operating system. A key part of Project Crossbow is a virtualization layer for networking interfaces to improve scalability and optimization.
Sun and FreeBSD are hardly strangers, with Sun technology helping out in the FreeBSD 7.1 release earlier this year.
Expect to see similar approaches showing up in FreeBSD, as well.
"Virtualization will be part of my future work," Li said. "As a FreeBSD developer who works for Blue Coat, my areas of focus will continue to be virtualization, TCP optimization and tuning with additional IPv6 support."
Sunday, August 23, 2009
Sunday, August 9, 2009
Google Chrome: Meet the New Boss
Google Chrome may not be the perfect Web browser, if there is such a beast, but it’s definitely going to give Firefox and Internet Explorer a run for their money. Even though Chrome is still in developer preview for Linux, it’s already making great strides.
For the past week or so, I’ve been running Google Chrome as my primary browser. Ben Kevan has been making packages for openSUSE for a while, and I finally decided to take the plunge. Initially, I thought I’d take it for a spin and go back to Firefox — which is what usually happens when I try a different browser. This time around, I may be sticking with Chrome for most of my browsing.
Speed, Stability, Extensions: Pick Two
Installing Chrome on openSUSE was a snap — just install an RPM and Chrome is ready to go. At first launch, Chrome will offer to import your settings from other browsers. It sucked in my Firefox options flawlessly, including bookmarks and passwords.
The first thing that I noticed with Chrome is that it’s speedy. Really speedy. Sites seem to load a little faster and the browser user interface (UI) itself seems a little snappier. This seems particularly true when using Google services like GMail and Google Reader, but for the most part holds true across other sites as well. On occasion, though, some Web elements don’t seem to want to work with Chrome at all. For instance, posting into an older version of WordPress, some of the menus when rendered in Chrome do not work, period. This is rare, but crops up for me at least once or twice per day.
In addition to being speedy, though, Chrome is also rock-solid stable. Since Chrome on Linux is still in development and not considered a “stable” release, I wasn’t expecting great things in the stability department. After a day of browsing with no crashes, I was impressed. After a week with almost no problems with Chrome, I’m deeply impressed.
The build I used is almost feature complete, although there seems to be no support for printing — which is probably good for the environment, but not so hot when you need to actually print things. There is a context menu item for printing, but nothing happens when I select the option. I assume that the Chrome folks will get around to this one eventually.
Chrome’s UI is a bit non-standard. Instead of the usual set of menus, Chrome just has a couple of icons to the right-hand side of the interface next to the location bar. This works pretty well, though it was a bit odd at first. By default, Chrome shows no “home” button, though this can be enabled in the Options.
The location bar doubles as the search bar, and the standard Ctrl-K shortcut will bring you to the location bar to perform your search. Since I’m used to this shortcut from Firefox, I fell into using it immediately. For users who aren’t, though, I wonder how they would discover the shortcut. There’s no clue in the UI that I could find that would help the user out here. You can find a list online but it’d be nice to have a menu item as well.
In case you’re wondering, yes — you can switch the default search engine. If you prefer to use Yahoo, Bing (still listed as “Live Search” in the option), Wikipedia, or another site, you’re free to do so.
Compared to the other popular browsers, Chrome has a very stripped-down set of features and options. However, I had trouble actually finding any features missing that I couldn’t live without, excepting printing. What I do miss is some of the extensions I use heavily in Firefox, like Xmarks and Evernote. For some reason, I couldn’t get Flash working in Chrome either (even with the –enable-plugins option) though I can’t say I really missed Flash very much.
One thing bugs me about Google Chrome — being bugged to make it the default browser. I’m not quite sure why browser designers feel the necessity to implant nagware into otherwise nifty software. Prompt once, and then let it go, folks. Chrome isn’t alone in this, but it’s still an unnecessary annoyance.
Chrome on Linux is still a work in progress, but it seems good enough to use full-time if you don’t mind reverting to Firefox or another browser occasionally. For the most part, I’ve been able to rely on Chrome as my primary browser and probably will continue using Chrome on my main desktop for the foreseeable future.
For the past week or so, I’ve been running Google Chrome as my primary browser. Ben Kevan has been making packages for openSUSE for a while, and I finally decided to take the plunge. Initially, I thought I’d take it for a spin and go back to Firefox — which is what usually happens when I try a different browser. This time around, I may be sticking with Chrome for most of my browsing.
Speed, Stability, Extensions: Pick Two
Installing Chrome on openSUSE was a snap — just install an RPM and Chrome is ready to go. At first launch, Chrome will offer to import your settings from other browsers. It sucked in my Firefox options flawlessly, including bookmarks and passwords.
The first thing that I noticed with Chrome is that it’s speedy. Really speedy. Sites seem to load a little faster and the browser user interface (UI) itself seems a little snappier. This seems particularly true when using Google services like GMail and Google Reader, but for the most part holds true across other sites as well. On occasion, though, some Web elements don’t seem to want to work with Chrome at all. For instance, posting into an older version of WordPress, some of the menus when rendered in Chrome do not work, period. This is rare, but crops up for me at least once or twice per day.
In addition to being speedy, though, Chrome is also rock-solid stable. Since Chrome on Linux is still in development and not considered a “stable” release, I wasn’t expecting great things in the stability department. After a day of browsing with no crashes, I was impressed. After a week with almost no problems with Chrome, I’m deeply impressed.
The build I used is almost feature complete, although there seems to be no support for printing — which is probably good for the environment, but not so hot when you need to actually print things. There is a context menu item for printing, but nothing happens when I select the option. I assume that the Chrome folks will get around to this one eventually.
Chrome’s UI is a bit non-standard. Instead of the usual set of menus, Chrome just has a couple of icons to the right-hand side of the interface next to the location bar. This works pretty well, though it was a bit odd at first. By default, Chrome shows no “home” button, though this can be enabled in the Options.
The location bar doubles as the search bar, and the standard Ctrl-K shortcut will bring you to the location bar to perform your search. Since I’m used to this shortcut from Firefox, I fell into using it immediately. For users who aren’t, though, I wonder how they would discover the shortcut. There’s no clue in the UI that I could find that would help the user out here. You can find a list online but it’d be nice to have a menu item as well.
In case you’re wondering, yes — you can switch the default search engine. If you prefer to use Yahoo, Bing (still listed as “Live Search” in the option), Wikipedia, or another site, you’re free to do so.
Compared to the other popular browsers, Chrome has a very stripped-down set of features and options. However, I had trouble actually finding any features missing that I couldn’t live without, excepting printing. What I do miss is some of the extensions I use heavily in Firefox, like Xmarks and Evernote. For some reason, I couldn’t get Flash working in Chrome either (even with the –enable-plugins option) though I can’t say I really missed Flash very much.
One thing bugs me about Google Chrome — being bugged to make it the default browser. I’m not quite sure why browser designers feel the necessity to implant nagware into otherwise nifty software. Prompt once, and then let it go, folks. Chrome isn’t alone in this, but it’s still an unnecessary annoyance.
Chrome on Linux is still a work in progress, but it seems good enough to use full-time if you don’t mind reverting to Firefox or another browser occasionally. For the most part, I’ve been able to rely on Chrome as my primary browser and probably will continue using Chrome on my main desktop for the foreseeable future.
Sunday, August 2, 2009
Debian GNU/Linux 6.0 "Squeeze" release goals
Following up on its decision to adopt the policy of timed release freezes beginning with the next release of Debian GNU/Linux, the Debian Release Team has now published their list of release goals for the upcoming release of Debian GNU/Linux 6.0, code-named "Squeeze".
In the light of these goals and also in consideration of the Debian community's feedback to the release team's initial announcement during the keynote of this year's DebConf in Caceres, Spain, the Release Team has additionally decided to revisit its decision on December 2009 as the proposed freeze date. A new timeline will be announced by the Debian Release Team in early September.
Luk Claes, Debian Release Manager, underlines the team's commitment to quality saying "In Debian we always strive to achieve the greatest quality in our releases. The ambitious goals that we have set for ourselves will help to secure this quality in the upcoming release."
The Debian Release Team - in cooperation with the Debian Infrastructure Team - plans to include the following goals in the upcoming release:
* Multi-arch support, which will for instance improve the installation of 32 bit packages on 64 bit machines
* kFreeBSD support, introducing the first non-linux architecture into Debian
* Improved boot performance using dash as the new default shell, and a dependency-based boot system that will both clean up the boot process and help performance through parallel processing
* A further enhanced Quality Assurance process resulting in higher quality packages. This includes:
o Clean installation, upgrade and removal of all packages
o Automatic rejection of packages failing basic quality checks
o Double compilation support
* Preparation for new package formats to help streamline future development and to introduce improved compression algorithms
* Removal of obsolete libraries for improved security
* Full ipv6 support
* Large File Support
* Automatic creation of debug packages for the entire archive, a Google Summer of Code Project pending integration into the infrastructure
* Move of packages' long descriptions into a separate "translated package list", which will facilitate their translation and also provide a smaller footprint for embedded systems thanks to smaller Packages files.
* Better integration of debtags, a system to tag packages with multiple attributes for easier package selection
* Discard and rebuild of binary packages uploaded by maintainers, leaving only packages build in a controlled environment
The Debian Project looks forward to working with its many upstream projects and the worldwide community of Free Software developers in preparing the next high-quality Debian release.
In the light of these goals and also in consideration of the Debian community's feedback to the release team's initial announcement during the keynote of this year's DebConf in Caceres, Spain, the Release Team has additionally decided to revisit its decision on December 2009 as the proposed freeze date. A new timeline will be announced by the Debian Release Team in early September.
Luk Claes, Debian Release Manager, underlines the team's commitment to quality saying "In Debian we always strive to achieve the greatest quality in our releases. The ambitious goals that we have set for ourselves will help to secure this quality in the upcoming release."
The Debian Release Team - in cooperation with the Debian Infrastructure Team - plans to include the following goals in the upcoming release:
* Multi-arch support, which will for instance improve the installation of 32 bit packages on 64 bit machines
* kFreeBSD support, introducing the first non-linux architecture into Debian
* Improved boot performance using dash as the new default shell, and a dependency-based boot system that will both clean up the boot process and help performance through parallel processing
* A further enhanced Quality Assurance process resulting in higher quality packages. This includes:
o Clean installation, upgrade and removal of all packages
o Automatic rejection of packages failing basic quality checks
o Double compilation support
* Preparation for new package formats to help streamline future development and to introduce improved compression algorithms
* Removal of obsolete libraries for improved security
* Full ipv6 support
* Large File Support
* Automatic creation of debug packages for the entire archive, a Google Summer of Code Project pending integration into the infrastructure
* Move of packages' long descriptions into a separate "translated package list", which will facilitate their translation and also provide a smaller footprint for embedded systems thanks to smaller Packages files.
* Better integration of debtags, a system to tag packages with multiple attributes for easier package selection
* Discard and rebuild of binary packages uploaded by maintainers, leaving only packages build in a controlled environment
The Debian Project looks forward to working with its many upstream projects and the worldwide community of Free Software developers in preparing the next high-quality Debian release.
Subscribe to:
Comments (Atom)
