Yesterday Phoronix published an article benchmarking the ext3, ext4, xfs, btrfs and NILFS2 filesystems based upon the 21/06/2009 daily build of Ubuntu 9.10 (Linux 2.6.30). The tests used a 7200RPM SATA 2.0 Seagate ST3250310AS drive and unfortunately didn't use any fast Solid State Drives.
Kudos to Phoronix for producing a wide set of benchmarks. The results show ext4 proves to be a good all-rounder choice. However, a few things to remember are:
1) Ubuntu 9.10 will be 2.6.31 based, so expect some improvements with btrfs in the newer kernel.
2) Ubuntu will have some SSD based optimisations, such a aligning the partitions to natural flash block boundaries to squeeze more performance out of SSDs.
SSDs are becoming more popular on netbooks and laptops, and with the benefit of excellent random seek time and fast parallel block read/writes (assume 2,4 or 8 way native striping on the SSD) the landscape may change with respect to benchmarkable filesystem performance.
I suspect we will see btrfs get tweaked and tuned more over the next 6-12 months, and perhaps ext4 will lose it's crown on the Phoronix tests.
What ever happens, the move to SSD and the focus on ext4 vs btrfs will lead to faster booting and more efficient filesystem performance. Onward and upward!
Tuesday, 30 June 2009
Monday, 29 June 2009
Ubuntu Kernel Team Knowledge Base
The Ununtu Kernel Team Knowledge base is a wiki page containing all sorts of Kernel related know-how, tricks and tips and runes. We try to keep it up to date, and we hope it will help anyone who wants to build their own kernels or generally wants to poke around at all things kernel related.
Please feel free to visit this wiki page and look around, read and contribute too! We believe that good know-how should be documented and shared around, so we welcome contributions and corrections! Enjoy!
Please feel free to visit this wiki page and look around, read and contribute too! We believe that good know-how should be documented and shared around, so we welcome contributions and corrections! Enjoy!
Sunday, 28 June 2009
Some Much Complexity, So Little Time
There used to be a time when one could get to understand how things worked. For example, back in the late 80's I had a Commodore 64 and after spending many hours pouring over Kernal ROM disassembly books I got pretty familiar with how it ticked. I even had a hefty 1541 drive disassembly reference book as I was trying to figure out how to write turbo loaders. OK, so I didn't have the original source, but I had time, and there was only tens of thousands of lines of assembler to understand.
Nowadays, things are radically different. The Linux Kernel is huge: Millions of lines of C and some assembler, tens of thousands of lines change between versions, but we at least have the source (and documentation!). There just is not enough time in the day to get to understand all of it well enough!
Fortunately there are well defined interfaces and well documented sub-systems, but I fear we are in an age were no mere mortal can fully understand exactly what is going on in the kernel. Complexity reigns.
A typical week may see me dipping in and out of different parts of the kernel - looking at wifi, audio and ACPI. Figuring out BIOS interactions and trying to work out the best kernel tweaks to sort out issues. It can be like an intellectual game, figuring out exactly how some parts work or interact with hardware for the first time can be a challenge, but equally, very rewarding too. Some bugs sometimes seem like they just cannot happen, then you get some different insight to how a system is behaving and then you get that "ahah!" moment and everything becomes very clear and you get a solution, and this is very satisfying indeed.
So, in a way, it's good that the kernel is so large, complex and mysterious in places. There is plenty of scope to keep my gray cells busy; always new features to learn about, new twists to negotiate, new things to discover.
I may get nostalgic about the good old days where life was simpler, code was smaller and less of it to comprehend, but less face it, I'd rather be working on the Linux kernel than writing 8 bit 6510 assembler any day :-)
Nowadays, things are radically different. The Linux Kernel is huge: Millions of lines of C and some assembler, tens of thousands of lines change between versions, but we at least have the source (and documentation!). There just is not enough time in the day to get to understand all of it well enough!
Fortunately there are well defined interfaces and well documented sub-systems, but I fear we are in an age were no mere mortal can fully understand exactly what is going on in the kernel. Complexity reigns.
A typical week may see me dipping in and out of different parts of the kernel - looking at wifi, audio and ACPI. Figuring out BIOS interactions and trying to work out the best kernel tweaks to sort out issues. It can be like an intellectual game, figuring out exactly how some parts work or interact with hardware for the first time can be a challenge, but equally, very rewarding too. Some bugs sometimes seem like they just cannot happen, then you get some different insight to how a system is behaving and then you get that "ahah!" moment and everything becomes very clear and you get a solution, and this is very satisfying indeed.
So, in a way, it's good that the kernel is so large, complex and mysterious in places. There is plenty of scope to keep my gray cells busy; always new features to learn about, new twists to negotiate, new things to discover.
I may get nostalgic about the good old days where life was simpler, code was smaller and less of it to comprehend, but less face it, I'd rather be working on the Linux kernel than writing 8 bit 6510 assembler any day :-)
Increasing Wifi Beacon Interval to Save Power
I was reading "802.11 Wireless Networks" (Matthew S Gast, O'Reilly, ISBN 0-596-00183-5) and stumbled upon the fact that increasing the Beacon Interval on an Access Point (AP) can be a good thing. Firstly, the default setting on my AP was 50ms which means all my Wifi enabled kit in the house is being interrupted 20 times a second, which is a tad excessive. By increasing the interval to 1000ms my laptop is interrupted less frequently and hence saves some power. Secondly, increasing the beacon interval means I get a little more available channel capacity for my data.
The downside is that passive scans of the network take a little longer and also mobile devices on my network cannot move about so rapidly while maintaining network capacity - but this is not a big deal for me since my laptops generally stay fixed on my desk, dining room table or lap.
So now I've tweaked this setting powertop is reporting that iwl3945 wifi interrupts have dropped significantly from ~20/sec to ~1/sec on a idle system.
The beacon intervals section of the Less Watts Wifi power management page also concurs with this as being a good way to reduce power consumption. Scale this up in an office environment when tens of machines are connected to an AP, and you start to see some valid reasons for making this change to the default setting.
~
The downside is that passive scans of the network take a little longer and also mobile devices on my network cannot move about so rapidly while maintaining network capacity - but this is not a big deal for me since my laptops generally stay fixed on my desk, dining room table or lap.
So now I've tweaked this setting powertop is reporting that iwl3945 wifi interrupts have dropped significantly from ~20/sec to ~1/sec on a idle system.
The beacon intervals section of the Less Watts Wifi power management page also concurs with this as being a good way to reduce power consumption. Scale this up in an office environment when tens of machines are connected to an AP, and you start to see some valid reasons for making this change to the default setting.
~
Subscribe to:
Posts (Atom)