Building a fast low-power home server

In my home, I have a need for a fast NAS box that, while not in use, uses as little power as possible. My requirements are basically:

* 1 TB of harddisk space, mirrored (RAID-1).
* Fast NFS (possibly SMB) throughput (think >= 50 MByte/s).
* Always on: The server will run Tor, and should be reachable 24/7.
* Silent when not in use: Harddisks should be powered down when not in use.
* Economical when not in use: I am aiming for 10 W when not in use.
* Open and flexible: Should run a normal commodity OS (say: Ubuntu server), and write data to disk in an open format (so that, should be motherboard crash, I can connect the disk to another Linux system and read it).

The Qnap TS-209 Pro that I bought last year does not really fit the bill; Qnap cheaped out on the CPU, and put a Geode 800 (500 MHz) in, which results in the server being CPU bound at a NFS read/write rate of ~22/15 MByte/s.

The new system will be based on the very economical (let reasonably fast) VIA C7 line of CPUs. The mainboard (which comes as a package with a NanoBGA 1.8 GHz C7 on it) is a VIA EPIA SN-18000G. This mainboard has a low power usage when not in use, yet is reasonably fast. A really nice touch on this mainboard is that one can actually put a CF card in a slot on the bottom; I'll be using a CF card here to boot my system from, so that I can spin down the harddisks when not in use, but more on that in a later post.

Anyway, this is the hardware list:

* Mainboard/CPU: VIA EPIA SN-18000G w/ 1.8 MHz NanoBGA C7.
* 2 x 1 GB DDR2/PC5300 RAM.
* A Kingston Elite Pro 16 GB CF Card (SLC, for reliability).
* 2 x 1 TB WD10EADS "Caviar Green" hard drives.

The harddrives are notable for the fact that they have a < 3 W power usage when idle, and a ~0.4 W power usage when spun down.

I'll be assembling my system tonight... More info (including actual power-usage measurements) is on its way.

IPv6 on OpenWRT (with SixXS)

As I wanted to be part of the IPv6 net at home, I registered at http://www.sixxs.net and applied for a tunnel. And what do you know: They had a PoP in the very city where I live (Zurich). The next step (after my tunnel was enabled), was to enable IPv6 on my Linksys WRT54G v2.2 running OpenWRT Kamikaze.

There are some guides on setting up IPv6 on OpenWRT (e.g., http://wiki.openwrt.org/IPv6_howto ), but they leave out some important details. The guides advise you to install:

ipkg install kmod-ipv6
ipkg install radvd
ipkg install ip
ipkg install kmod-ip6tables
ipkg install ip6tables
ipkg install aiccu

However, in order to have things work properly over a SIT tunnel (which is what SixXS uses), you need to install three additional packages:

ipkg install kmod-iptunnel4
ipkg install kmod-tun
ipkg install kmod-sit


After installing these, and getting you SixXS tunnel confirmation mail, edit /etc/aiccu.conf but do not set the server's IP address in this file; AICCU will figure that out for you.

A simple AICCU should now do the trick, and indeed:

root@:~# ping6 -c 4 ipv6.google.com
PING ipv6.l.google.com (2001:4860:0:1001::68): 56 data bytes
64 bytes from 2001:4860:0:1001::68: icmp6_seq=0 ttl=55 time=54.3 ms
64 bytes from 2001:4860:0:1001::68: icmp6_seq=1 ttl=55 time=52.9 ms
64 bytes from 2001:4860:0:1001::68: icmp6_seq=2 ttl=55 time=56.0 ms
64 bytes from 2001:4860:0:1001::68: icmp6_seq=3 ttl=55 time=54.8 ms

Google Gears on Ubuntu 7.x

When trying to install Google Gears on Firefox on Ubuntu 7.x, I failed miserably; The Firefox add-on manager would claim to install Gears, but after a Firefox restart, gears would still not be installed.

Fortunately, I was not the only one having this problem, and the others facing this problem already found a solution. Details can be found, e.g., here.

A quick summary of the problem and the solution: the problem is that Gears uses a C++ library that is not installed by default on Ubuntu 7.x. The solution is easy though, run

sudo apt-get install libstdc++5

to install the missing library, restart Firefox, revisit gears.google.com, and off you go!

Garmin GPSMap 60Cx and EGNOS - Finale

After two earlier posts on the trouble I had with getting EGNOS to work on the Garmin GPSMap 60Cx, it seems that the trouble are now solved because of Garmin's latest GPS-chipset firmware upgrade.

As of February 18, 2008, the 3.60 firmware is available for the GPSMap 60Cx itself. This update changes some small maps things unrelated to EGNOS. There also is an update for the GPS Chipset type G, and it seems that this update did the trick for EGNOS. I now routinely get good SBAS signals on either Garmin channel 33, 37, or 39. The smallest EPE I have seen so far is 3 m -- a little more than I expected, but this might have been caused by a poor constellation.

The attached image show a nice 4-m EPE under some tree cover at an old fortress near Lake Zurich.

Thanks, Garmin!

Experimenting with OpenSocial

Google's OpenSocial allows one to automatically connect his identities on multiple public profile sites. See, e.g., http://code.google.com/apis/socialgraph/ .

These are a few of my identities:

Hyves: me
Plaxo: me
LinkedIn: me
OpenID: me
Bergboer.net: me

Basically, all that is needed to establish one's identity, is a bidirectional pair of rel="me" links. So, if this site points to niekbergboer.bla.com (say) with a rel="me" attribute, and that site points back to this site with the same attribute, OpenSocial will pick up the fact that these sites all belong to me identity.

Many sites, however, do not allow one to directly edit the rel attribute of a link. In that case, just add a plaintext link. Things should still work, as long as at least one link of the pair has a rel="me" tag.

An update on Garmin and EGNOS

In my previous post, I ranted about the fact that my new Garmin GPSMAP 60Cx would not use EGNOS signals, whereas my old GPS 60 would. However, this weekend I took my GPSMAP with me on a hike, and at a certain post I noticed that I had indeed obtained a differential fix (and a EPE of about 3 m).

Today, this happened again, but now I had my camera handy to catch the unit in the act (see left). The image clearly shows a differential fix, where Garmin channel #33 (PRN 120) is providing the differential corrections. The second thing that stands out, is that the bar for channel 33 is solid (rather than open). On my GPS60, the EGNOS bar would usually be open, but I would still get differential corrections. It happened to me only once on the GPS60 that the EGNOS bar was solid. After asking around on usenet, I appeared that an EGNOS' satellite bar is solid only if the EGNOS satellite sends actual ranging data for itself,
in addition to the correction data for the other satellites.

It seems that the GPSMAP 60Cx uses EGNOS perfectly, but only if the EGNOS satellite sends out ranging data for itself in addition to correction data for the other satellites. Does anyone have any experience on this with WAAS? Do WAAS satellites do this?

Garmin and EGNOS

A little while ago, I bought a Garmin GPSmap 60Cx to replace my Garmin GPS 60. The GPSmap 60Cx provides (as the name implies) mapping functionality, and it also has the very sensitive SiRF III GPS receiver that the GPS 60 did not have.

The sensitivity of the GPSmap 60Cx is spectacular compared to that of the GPS 60: I can get a fix indoors, and outdoors the EPE rarely ever gets above 5 meters CEP.

However... whereas my GPS 60 happily picked up the EGNOS (WAAS for Europe) signals at Garmin channels 33 and 39 (and sometimes 37), the improve the accuracy to 1 to 2 meters CEP, the GPSmap 60Cx bluntly refuses to use these signals. The unit recognises _very_ strong signals on channels 33 and 39, but then decides not to use it after about 30 seconds. After some discussion and searching on the internet, it seems that EGNOS currently still sends out a "testing" flag in its correction signals. The GPS receiver in the GPS60 would happily use the signals anyway, but the SiRF III firmware in the GPSmap 60Cx actually honours the testing flag, and thus (correctly by design) refuses to use them.

That may all be very well according to the standards, but my experience with EGNOS has been very good on the GPS 60. I would therefore like to use it on the GPSmap 60Cx as well, and I'm willing to take the risk of these signals not being 100% reliable.

Now, it seems that it is possible to force some chipsets into using testing signals anyway, as posted here. However, it is not clear whether this will work with the SiRF III chipset as well. In addition, these commands seem to work on a serial link only, while all I have is a USB cable, and my laptop has no serial port.

We'll see...