ping

Netgear lies! 802.11n will (probably) not give you higher speed and better coverage

When my ADSL modem and Wi-Fi access-point died I decided I might as well buy the latest and greatest even though 802.11n was still a draft standard. So I bought a new 802.11n Wi-Fi access point/router/ADSL modem (Netgear DG834N) and I fitted 802.11n PCI cards (Netgear WN311B) into the various PC’s we have in the house.

802.11n was supposed to give me wider coverage and higher speed. “Supposed to” is the key in the previous sentence. I have absolutely no better coverage than with 802.11g and the real bandwidth is only very marginally better.

I decided to test using ttcp which is a program that only tests the actual network pipe, it is not a fileserver test. In all tests I ran one copy of ttcp on my Linux server and another copy on the workstations. I first ran ttcp on the PCs equipped with 802.11n PCI cards and then I ran, from the exact same location, the same test on my laptop which is equipped only with 802.11g. So when I say there is no real difference in the network performance it is not just a guess or a feeling, it is based on facts.

I just couldn’t understand why I didn’t get any of the supposed benefits of using pure 802.11n equipment, much higher speed and better coverage, so I did a bit of research (otherwise known as Googling), and this is what I learnt.

The 802.11n standard supports data transmission both in the 2.4 and in the 5 GHz frequency bands. The 2.4 GHz frequency band is the same one used by the 802.11b and 802.11g standards. Where I live I can detect 12 other 802.11g-based access-points. My Netgear DG834N device only supports data-transmission in the 2.4 GHz frequency band which it has to share with all the other access-points. My access-point supports something called “channel expansion mode” to achieve the theoretical 270Mbps, and it can’t do that as it has to avoid problems with the transmission from the other non-802.11n access-point. High bandwidth using the 2.4 GHz frequency band is only possible where there are very few or no other access-points using that frequency band. In other words, if you are in the same situation as I am, lots of neighbours with 802.11b or 802.11g-based access-points, either forget about buying 802.11n-based equipment, or ensure the 802.11n equipment you buy supports the 5 GHz frequency band.

I must admit to feeling cheated. On their website Netgear show how 802.11g gives you speed 1x and coverage 1x whereas 802.11n supposedly gives me 15x speed and 10x coverage. Nowhere did they tell me that would only be the case if the airwaves where practically free of data-transmissions from other 802.11g-based access-points. Since I bought the Netgear DG834N access-point, they have released a dual-band access-point. In other words, it supports both the 2.4 and the 5 GHz frequency bands. And guess what, they do actually tell you on the page for that device that “Dual band wireless networks deliver better connections with less interference”. Come clean Netgear (and other Wi-Fi vendors), tell it as it is, 802.11n-based access-points with 802.11n clients that only support the 2.4 GHz frequency band are probably not going to be any faster than are a 802.11g-based access-point.

Amongst my sources:

• 802.11n – The consequences of abandoning the 5 GHz frontier
• The truth about 802.11n, 2.4Ghz and 5.8Ghz

Tags: 2.4 GHz, 5 GHz, 802.11g, 802.11n, lies, Netgear

Reclaim disk space on ext3 filesystems

My Linux server is running out of disk space, and so are the external disks I’m using for backing up my data. I have also wanted to make the backup process from internal disks to external disks faster, and while searching the internet for ways to optimise that, I stumbled upon a fast, easy and safe way to gain extra usable disk space. I’m slightly embarrassed that I have only discovered this trick until now.
When an ext2 or ext3 filesystem is created, it sets space aside. To quote from the “man” pages for mkfs.ext2 and mkfs.ext3:
“-m reserved-blocks-percentage: Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.”
My external backup disks have absolutely no need for this reserved space; nevertheless the default filesystem set 5% of it aside for root-owned daemons which will never write to the external disks. This is what df showed for one of my external disks:

Filesystem     Size  Used Avail Use%
/dev/sde1      459G  433G    3G 100%

So 459-(433+3)=23GB I can’t use, the 23GB are the 5% of 459GB set aside and seemingly lost unless I create a new filesystem and use the “-m” parameter.

Luckily this can be changed on an existing but unmounted filesystem using the tune2fs command. So in my case
"tune2fs -m 0 /dev/sde1"
gave me back the 23GB reserved diskspace on the external disks. On my fileserver, /home sits on three 300GB disks setup in a RAID-5 array and root-owned daemons don’t write to /home. Using
"tune2fs -m 0 /dev/md0"
gave me back almost 28GB diskspace on the /home partition. I can now wait another couple of months before I replace the disks.

The following links are the ones that opened my eyes:
http://boncey.org/2006_11_18_reclaiming_ext3_disk_space
http://ubuntuforums.org/showthread.php?t=215177&page=2

Tags: diskspace, ext3, filesystem, raid, reclaim mkfs, tune2fs

The Sagem PVR 6280T has left the building

It has been replaced by a Humax PVR-9200T. The Sagem box had a number of peculiarities that have never been fixed by Sagem even though it has had a couple OTA (Over The Air) upgrades. When I got close to its 1-year anniversary I had actually decided to see what Tesco would say if I tried to return it under warranty, but buying and moving house at the same time meant that I never got around to it. Its worst peculiarity happened if you were viewing a recording and a new timed recording kicked in. It would briefly switch to the channel on which the recording was about to take place, stay there for a few seconds and then return to what you had been watching all along. But even though its peculiarities were really annoying at times, its ultimate downfall in this household was the size of its hard disk. The fact that we don’t actually se that much TV means that the hard disk was usually more than 75% full because of recordings we wanted to see sometime.

The Humax has a 160 GB hard disk, so it should in theory make life easier for us. It is of course a possibility that all that happens is that it will take us longer to get to the 75% mark and then we will be back where we started. If that happens, I plan on using the USB plug and take some of the recordings of it.

So what is there to like or dislike about the Humax device compared to the Sagem box (some of these features are not unique to the Humax, but they are features the Sagem didn’t have):

• If something I want to record is part of a series, and I choose to record, it asks if I want the whole series or just that particular program.
• Rather just having the ability to choose to record from the EPG or via date-and-time programming, there is a “Find” option where I can search by name or part of the name or I can choose a genre such as “Movies” or “Education” and scroll through the resulting list. After I discovered that, I haven’t used the EPG list at all.
• I like and dislike the remote. It is much bigger than the remote for the Sagem, and most of the buttons are much better laid out. On the Sagem I frequently pressed the wrong button. Unfortunately, some of the potentially useful buttons are under a sliding panel which doesn’t seem that sturdy, and I just don’t use them because they are under that panel.
• The Humax can make two recordings simultaneously. Even though the Sagem box has twin tuners, it can’t make more than one recording at a time.
• If I choose to record something which conflicts with something else I’ve already set to record, the Humax will show me the conflicting recordings, and I can choose to replace or leave alone. On the Sagem, it would just ignore you.
• The EPG take ages to fill with data compared to the Sagem. I knew about this from comments on the internet, so it wasn’t a surprise. The other features of the Humax outweigh this downfall, but it really does take a surprisingly long time to fill up.
• Getting to the list of available recordings was actually better on the Sagem. One click on the “List” button would bring, well, the list of recordings up where you could see all details of the recordings such as date and time the recording was made, from which channel etc. Highlighting one of the recordings and clicking “Ok” would start the playback. The closest thing to this simplicity on the Humax involves pressing one of the buttons hidden underneath the sliding panel, and the list that pops up is not very detailed in information. If you want the detailed information, you have to press “Menu” and then choose “Recordings” to get to a list with information similar to that displayed on the Sagem. When you then select a recording, it starts playing right away, but the menu interface is still on the screen as well, so you have to push the “Exit” button on the remote to get the menu interface away.
• There is an 8 GB partition on the hard disk which is reserved for JPEG pictures and/or MP3 audio files. Whether you use it or not, it is there and taking up exactly 8 GB of space. If you do use it, for many people 8 GB would turn out to not be enough, and for those who don’t use it, it is just wasting space.

At the time of writing, the cheapest place to get the Humax is at Dixons where you can get it for £159.94 (incl. shipping). They are frequently sold out at Dixons, so you’ll have to watch their website every now and then to check whether they are back in stock. Or you can buy my used Sagem box on eBay…

More on Converting RAID-1 to RAID-5 with no data loss

I have for a while had a RAID-1 disk array on my Linux based (Centos 5) home server. As I was beginning to run out of disk space, I wanted to add an extra disk and change it to a RAID-5 disk array thereby doubling the amount of disk space available.

My Dell PowerEdge 930 has a drive bay with room for 4 hard drives. The server originally came with a Western Digital 80 GB SATA drive. This contains everything, except for /home. 2 Maxtor DiamondMax 10 300 GB drives were originally setup in a software RAID-1 array. So to get that extra disk space, I bought a new hard disk that I wanted to add to the server and then turn the RAID-1 array into a RAID-5 array,
I was going to do it the hard way, take a backup, wipe away the old array, create a new one and restore the data. But I found a blog entry here that explains how to change it online. So this blog entry is first of all to tell anyone interested that it actually works, but also to document those steps that weren’t entirely clear (to me at least). It was quite some time ago that I created the original software RAID array on the server, so there were a few additional steps necessary that are not documented in the above. You need to follow the instructions in Scotts document, and you can then refer to my document in case you run into some of the same issues I did.

My home server hosts a couple of web sites, a mail server + several home services such as being a file server for, downtime had to be minimised which is why the in-place conversion appealed so much to me. I was even braver than Scott and except for a few actions where I stopped some services and then started them again shortly after when everything seemed all right, all services were active throughout the conversion

Stopping the RAID array
My server has no keyboard or monitor attached, so I was going to do this via ssh. That was only possible because I wasn’t touching the boot drive. If you want to do this with the boot drive, you need a real screen and keyboard attached and do what you are doing there. The mdadm –stop command would not stop the array and it took me a while to realise I had forgotten to umount the array. I couldn’t do that either, I kept being told that the device was in use or busy. The lsof command
lsof |grep /home
finally showed me the issue. I had logged in as a normal user and then issued the su command, so /home/users was in use. I needed to login directly as root.

New partition on new disk
The disks I originally purchased are no longer in production, and the new disk of course doesn’t have the same size as the original disks. Some Linux RAID documentation seems to imply that it doesn’t matter if the partitions are of different size, whilst other documents said that you would lose data if the partitions were not of the same size. I wasn’t going to experiment, so I made the partition on the new disk the exact same size as the partitions on the old disks. The simplest way to get a partition on the new disk to be similar to the partitions on the old disk is to use the sfdisk command which on my server meant I did
sfdisk -d /dev/sdb | sfdisk /dev/sdd

Re-shape process
Doing “cat /proc/mdstat” gives you statistics about the data transfer speed and the number of minutes it will take. The value for the data transfer speed was fairly consistently around 4000 KB/sec and it claimed it would ~1100 minutes. I tried speeding it up by manipulating the values for:
/proc/sys/dev/raid/speed_limit_min
/proc/sys/dev/raid/speed_limit_max
It didn’t seem to make any difference so I finally left it and went to bed. Next morning when I woke up it was finished reshaping, and I did not sleep for that long. As you can see from the graph, at some stage, it picked up speed and raced through the rest of the reshaping.

Resizing the array
Reading various RAID documentation makes it clear that there is an optimum “stride” value which is equal to the chunk size divided by the block size. In my case the chunk size is 64 KB and the block size is 4 KB, so the stride value should be 16. You can find the block size with
dumpe2fs –h /dev/md0
and the chunk size with
cat /proc/mdstat
The man pages for resize2fs “will heuristically determine the RAID stride that was specified when the file system was created”. I have no idea whether that means that it will pick the optimum stride value, so I chose to specify the value manually, so on my system I did
resize2fs –p –S 16 /dev/md0
By doing a du with one minute in between, I could see that the resize was happening at about 16 GB/min.

Summrary: It works, I had minimal downtime, and I essentially had two sets of data to operate on. The data on the array being converted and the data on the backup.

Dnsmasq

I’ve installed dnsmasq on my Linux server (Centos 5.1) and stopped BIND and dhcpd. I checked prior to stopping them, and BIND was taking up ~200 MB RAM. I run a mail server (Postfix) so the large amount of RAM used by BIND is probably due to all the DNS look-ups it has to perform. I will be interested in seeing how much RAM I now use.

Configuration was quite easy, certainly a lot easier than BIND and dhcpd. I did hit two challenges:

I started accepting lots of email for a domain that I do host a website for, but I don’t run email services for it. So it was never in my local named files, but I did include it in the /etc/hosts file which is where dnsmasq reads the dns names and ip addresses from. So I removed it from the hosts file and the email was still being accepted. When it couldn’t find the host, it sent a request to the upstream dns servers. That was solved by adding the parameter “local=/domain.tld” (with “domain.tld” being replaced with the domain name I use on the internal network).

I noticed a “log-queries” command which is supposed to log each DNS query. I was curious as to what that would look like, so I enabled it. Only, nothing happened. Strange, as the “log-dhcp” command worked fine. Eventually I found a reference in a mailing list somewhere that your syslog facility must be in debug mode, and it does mention that in the sample log file, but as the log-dhcp command worked without that, I had paid no attention to it.