Tune your wifi channel if you’re apartment living!

One thing I’ve noticed living here in this apartment is the shear number of wireless networks that propagate throughout my space. Personally I could care less what or where this signal comes from or goes to, however it does present a bit of a problem for reliability.

This is due to the fact that so many people tend to utilize the same channel (sub frequency) for their wireless networks that things get messy fast. I’ve seen everything from slow and unreliable wireless (feet away from the access point) to access point failure due to it having to negotiate so many other active access points sharing the same channel.

There is a solution and it’s quiet simple. In Linux using iwlist tool you can quickly pull a list of active networks around you, from there you can find (if you’re lucky) an unused channel, or at the very least the least used channel. Once you’ve discovered this change your router configuration, reboot if necessary and enjoy your much more stable and reliable connection.

$ iwlist wlan1 scanning | egrep 'ESSID|Channel' 
                    ESSID:"BusyGiraffe"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"FBI Surveillance Van #13"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"BusyGiraffe-guest"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"erics wire"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"<hidden>"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"myqwest1123"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"myqwest3115"
                    Frequency:2.412 GHz (Channel 1)
                    ESSID:"unixgr"
                    Frequency:2.427 GHz (Channel 4)
                    ESSID:"lynxandloki"
                    Frequency:2.432 GHz (Channel 5)
                    ESSID:"eany"
                    Frequency:2.437 GHz (Channel 6)
                    ESSID:"belkin.4d2"
                    Frequency:2.437 GHz (Channel 6)
                    ESSID:"Burton"
                    Frequency:2.437 GHz (Channel 6)
                    ESSID:"Netgearhome"
                    Frequency:2.437 GHz (Channel 6)
                    ESSID:"BrightCedar"
                    Frequency:2.462 GHz (Channel 11)
                    ESSID:"BrightCedar-guest"
                    Frequency:2.462 GHz (Channel 11)
                    ESSID:"FatBottomGirls"
                    Frequency:2.462 GHz (Channel 11)
                    ESSID:"FatBottomGirls-guest"
                    Frequency:2.462 GHz (Channel 11)
                    ESSID:"THC137"
                    Frequency:2.462 GHz (Channel 11)
                    ESSID:"TanushArinjay"
                    Frequency:2.462 GHz (Channel 11)

As you can see, channel 4 was available so I snatched it up (even though it’s overlapping), channels 1,  6 and 11 being extremely busy as they’re the the only non-overlapping channels available, so they’re set by default on most consumer access points.

Great set of file system benchmarks over at alephnull

Over at alephnull they’ve put together a really nice set of file system benchmarks, tracking all softs of various options which can improve and hurt performance when running in various mdraid configurations. From their site:

Linux Software RAID Performance Comparisons (2012)

The goal of this study is to determine the best configuration parameters for a 5-spindle software RAID using Linux as an NFS file server for Big Data analysis and (mostly write) backup storage.

Large sequential read and write access of files ranging from about 512mb to 4gb is particularly interesting.

Those with more spindles, more users, or more complex I/O patterns should not expect these results to apply to or scale to their environment.

Experimental details are provided below. Here is a summary of the recommendations.

A Comparison of Chunk Size for Software RAID-5

A Comparison of Cache Size for Software RAID-5

A Comparison of Payload Align Size for Cryptosetup Over Software RAID-5

A Comparison of Software RAID-5 With and Without Encryption and Ext4fs

A Comparison of Various Ext4fs Options

A Comparison of NFSv4 rsize and wsize Values

 

Linux Software RAID Performance Comparisons

The goal of this study is to determine the cheapest reasonably performant solution for a 5-spindle software RAID configuration using Linux as an NFS file server for a home office. Normal I/O includes home directory service, mostly-read-only large file service (e.g., MP3s), and nightly rsync-based backup.

Those with more spindles, more users, or more complex I/O patterns should not expect these results to apply to or scale to their environment.

Experimental details are provided below. Here is a summary of the recommendations.

A Comparison of Two Cheap 8-port SATA Controllers

When using software RAID, on mostly-single-threaded workloads, the Supermicro AOC-SAT2-MV8 has superior price/performance compared with the Promise SuperTrak STTX8650.

A Comparison of Chunk Size for Software RAID-5

The chunksize for 5-spindle RAID-5 should be 128KB (“mdadm … -c 128”).

A Comparison of Software RAID Types

RAID-5 and RAID-6 have nearly identical performance for I/O sizes less than about 256KB. Never use RAID-0.

A Comparison of Cryptographic Algorithms for Software RAID-5

AES-128 is fastest, although AES-256 is comparable for most workloads and should be considered for potentially better security.

When using a chunksize of 128KB for 5-spindle RAID-5, use the recommended full-stripe size of 512KB (1024 sectors) for the align-payload parameter for crypsetup.

A Comparison of Stride and Stripe-Width Values (for ext3 and ext4dev)

When using a 5-spindle RAID-5 with a chunksize of 128KB and a value of 512KB for the align-payload parameter, using the recommended stride of 128KB and stripe-width of 512KB is reasonable for both ext3 and ext4.

A Comparison of Ext3 and Ext4dev

Quite similar for these uncached tests. Ext4dev may provide better multi-threaded and mixed read/write performance.

A Comparison of Various NFS Configurations

Memory speed doesn’t much matter.

CPU speed is significant.

Larger [rw]size is better for multi-threaded workloads, but worse for single threaded workloads. 64KB is a good compromise.

Summary of Comparisons

For 5-spindle RAID-5, chunk size should be 128k. The AES-256 encrypted file system payload alignment should be 4 times this value, or 512k. The file system should be informed of these values as a stride of 128k and a stripe-width of 512k. For NFS, the rsize and wsize values should be at least 64k. NFSv4 should be used because it avoids lockd issues.

As a departure from this summary, consider AES-128 for improved write performance.

Final Build

After this analysis, the file server was built with the following commands:

  • fdisk -H 224 -S 56 /dev/sd[bcdef], start 1, end 155000
    The fdisk parameters were recommended by Ted T’so for SSDs and should not help with spinning media.
  • badblocks -b 4096 -s -v -w -t random /dev/sd[bcdef]1
    When running 5 copies simultaneously, 2 drives sustained 30MB/s writes, and the other 3 sustained 15MB/s — the difference being in the controller’s ports. Reads were 40MB/s on the two drives attached to the faster ports, and 20MB/s on the other ports.
  • mdadm -C /dev/md0 /dev/sd[bcdef]1 -c 128 -n 5 -l 5
    The -c parameter sets the chunk size to 128k. RAID reconstruction proceeded by reading at about 24MB/s from 4 disks and writing at 24MB/s to the other disk.
  • cryptsetup -c aes-cbc-essiv:sha256 -s 128 -h sha256 –align-payload=1024 luksFormat /dev/md0
    This uses aes-128 with a 512k payload alignment.
  • cryptsetup luksOpen /dev/md0 r0
  • pvcreate –metadatasize 506k /dev/mapper/r0
    This is also from Ted’s blog, but in this case I want to align the boundaries to 512k, since that is the payload alignment for encryption.
  • pvs /dev/mapper/r0 -o+pe_start
  • vgcreate -s 1g v0 /dev/mapper/r0
  • lvcreate -L 2t -n m v0
  • lvcreate -L 300g -n o v0
  • mke2fs -t ext4 -i1048576 -m0 -E stride=32,stripe-width=128 /dev/mapper/v0-m
  • mke2fs -t ext4 -i65536 -m0 -E stride=32,stripe-width=128 /dev/mapper/v0-o

Kubuntu “Network Manager Disabled” error 10.04 (Lucid)

If you’ve noticed that your knetworkmanager is no longer functioning, likely NetworkManager has gotten it self into a bad state. This can happen on unclean shutdown or crash of the NetworkManager application. That said the solution is quite simple

In a terminal session type:

sudo stop network-manager
sudo rm -f /var/lib/NetworkManager/NetworkManager.state
sudo start network-manager

This will remove the stale NetworkManager lock file and allow for proper operation. You should now find that knetworkmanager is functioning properly again.