As is typical of everything in the embedded world getting an OS up on the board presented a few challenges. I knew that I wanted to run debian on the board, I just had to figure out how to get it installed on to the microSD card. I picked up a 4GB class 4 card for the purposes of loading the OS and evaluating the board. Since there was no optical disk drive connected that ruled out the typical route of burning a debian install image. I couldn’t find a USB flash drive that I could format that was of sufficient size to load the install image on to. That left me with the option of putting the install image on a CF card using a USB CF card reader. Then, I booted the system with this drive and everything worked as though it would have with a USB flash drive. The only downside was the slow speed of the older CF card.

The install appeared to be going great, I got everything setup and I was ready for a reboot. So, I rebooted the system and I got nothing. Well technically I got the word “grub” printed on the screen and that was it. Thinking I had dorked something up I re-installed again, double checking everything. Same result! So, I decided to disconnect the USB CF card reader and try to boot up that way. Now I got even less! Just a flashing cursor. This told me that GRUB had some how gotten dorked up. So, I rewrote the installer image to CF card and booted up in rescue mode. I mounted my /boot partition by issuing mount /dev/mmcblk0p1 /boot. I looked at /boot/grub/device.map and I saw my problem immediately. My device.map read:

(hd0)   /dev/sda
(hd1)   /dev/mmcblk0

It was thinking that /dev/sda was my first disk, and that mmcblk0 was my second. It installed the MBR on /dev/sda (which is what was screwing up my CF card after the install), but didn’t create a partition for /boot. Which is why I only got “GRUB” on my screen. So, I changed the device map to reflect the true state of my system, and re-did a grub-install specifying the device map. Rebooted the system and I got a grub menu as I expected but still couldn’t boot! The grub menu was still pointing to (hd1) for the kernel image. A quick edit of the boot parameters and I was booting.

After a bit of frustration everything is up and going. So, now it is time to get my packages installed and make sure I can run the embedded app on this board! I’ll post some more benchmarks at a later date. I am expecting good performance given what I saw with the 1.1GHz board.

So, I set out today to solve my problem. I spent a good deal of time looking at the off-the-shelf products on the market. Every product seemed to have made some drawback that I wasn’t willing to accept. So, I finally caved and built a NAS system. The result is a system that serves all of my purposes and then some, while being energy conscious.

Here is a list of the components that went into the system:

• AMD Athlon LE-1640 processor
• 2GB of RAM (PC-6400)
• 3x 1.5TB Seagate 5900 RPM drives with 32MB buffer

After assembling all of that I installed Ubuntu Server 9.10 on it. The installation went off without much trouble. I created a RAID-1 volume of 256MB using all three drives for use as /boot. I used the remaining space on the drives to create a RAID5 array. This gave me about 3TB of space to work with. I dedicated this remaining space to LVM and created the following logical volumes:

• root (mounts at /) – 30GB formatted XFS
• home (mounts at /home) – 10GB formatted XFS
• share (mounts as /mnt/share) – 500GB formatted XFS
• swap (used as swap) – 8GB
• timemachine – 600GB
• unallocated – ~1.5TB

The share volume is served up using SAMBA to the various computers in the house (a couple of laptops, an iMac, etc.). The timemachine volume is exported using iSCSI to the iMac for use by TimeMachine.

A quick test showed that sequential writes to the share volume yielded about 130MB/s of sustained throughput on the server. Once I upgrade to a GigE switch I will perform the same test remotely and see what sort of performance I get.

Most people apply this principle to code for decomposition and overlook the actual data being stored. However, this should not be the case! Performance can suffer greatly when we aren’t diligent in making our data as DRY as possible.

When dealing with software where objects have a long lifetime the cost of construction gets ammortized to the point of non-existenince. However, for short lived objects the construction/destruction my consume the majority of the objects lifecycle. For these types of objects keeping things DRY is very important. I’ll discuss a case where DRYing out an object has very real performance consequences.

One example, would be using an object as identifiers for data objects. Take the following code as an example:

CBaseState *statePtr = NULL; // CBaseState is the base class for all state variables
statePtr = stateList[0]; // stateList is a std::vector

// every CBaseState has an ID field of type CBaseID, this is used to ID different states at runtime
// CPositionXID is derived from CBaseID
if (statePtr->GetID() == CPositionXID())
{
   printf("We have a XPosition state\n");
}

The class CBaseID is defined as:

class CBaseID
{
   StateEnum StateType;
   int ID[8];
   std::string IDString;
}

The equality operator checks the StateType and ID fields for equality. The IDString is a textual representation of the StateType and ID array. The IDString member is only used for display purposes in the debugger, and never referenced in the program.

The program creates 380,000,000+ instances of CBaseID derived classes during a typical processing run. Due to the creation of IDString the std::string constructor/destructor consumes 12% of the processing time! A simple change to DRY out the class yielded a 12% reduction in run-time.

The take away, don’t repeat data unnecessarily! If you can say something using one declaration, don’t use two. Make your tools work smarter, not harder.

When you convince a manager to purchase an expensive development tool you should be committed to learning what the tool is, and what it can do for you. Recently I’ve been looking at some code that a developer worked on long and hard. He attempted to make performance an important issue. The performance of this application is absolutely critical, as it is a vital step in processing data collected by field operations. The field personnel need to know in short order if their data is complete so they can demobilize. This becomes very important when you are in a line of work that has a $3,000 per day field cost. The developer who is no longer with the company convinced his manager that he needed IBM’s QuantifyPlus package. His manager saw a valid case for the purchase since there were known memory leaks in the problem, and the code base was in excess of 150,000 lines of code.

After getting this new tool, and sharpening it he set to work eliminating those pesky memory leaks. With the immediate fire extinguished a manager would have hoped that the developer took some time to figure out what other tools where added to his toolbox. Sadly, that developer did not do so. The true tragedy is that this expensive tool set included a performance analysis tool in addition to the memory analysis tool.

After having the code base in fresh hands for 18-months the software package is now capable of more robust processing operations, and runs in 1/2 the time that it used to. Further to that, the new developers armed with a toolbox that they know the contents of are striving to decrease the runtime even further.

Remember developers you are craftsmen, a craftsmen is nothing if they don’t know their tools. Sure, some of you may say that everything’s a nail for your hammer. But know what hammers you have, the 16lb sledge hammer is a poor fit for hanging that $5,000 piece of art in the hallway.

A future series of articles will discuss some of the steps the developers took to save so much processing time.

When we moved into the house last April there was no Uverse in the neighborhood. So, that left us with two options for broadband internet: Comcast HSI, and DSL. Having a burning hatred for Comcast I refused to go that route, so we phoned up AT&T and ordered a 1.5/768 DSL package. Everything looked great, a month later we hadn’t been installed and our order had been cancelled three times. I finally got someone to admit that they would never be able to provide DSL service at the address. So, I started investigating other options. Speakeasy came to my rescue. While they weren’t the cheapest option, they weren’t Comcast and they could give me service. I went with them and loved their customer service and their attention to detail.

This is where the fun part of the story begins. A couple of weeks ago we got a flier in the mail complete with trumpeters and everything, Uverse was available in my area! (okay, so there weren’t any trumpeters) My wife and I thought this was a great idea, we’d get to simplify our billing (we already had AT&T for wireless, and we could ditch DirecTV) and make our lives easier. We attempted to order online to get the $200 cash back reward. That is where things started going tits up.

Our order couldn’t be placed online because we had “conflicting service” at the address. So, we phone them up and the conflicting services was our DSL provided on a dry loop by Speakeasy through COVAD. Not be able to operate without the internet put us in a sticky situation. I was given an “advanced sales” number to call the next day during normal business hours. I called the next day and the lovely lady informed me that I had to cancel Speakeasy. She also told me that I could turn around and call back in right away and place my order and as soon as the line lock was released they could get me a 24 hour turn around on install. I was lead to believe that I would be without internet for 3 days or so. It turns out that is not the case and I should not have been told that. Based on what I had been told I went ahead and cancelled Speakeasy, and phoned them backup. This time a gentleman told me I would have to wait for the line lock to release and then I could place my order and that no 24 hour turn around on install existed. I was understandably furious. A week later we finally got the order in, they were able to override the line lock magically on the 6th day of calling. They told me that my line lock had to be off 24 hours prior to install or the order would be cancelled and my install date was 8 days from then. Once again I was enraged. So, I set to work figuring what was going on with the line lock. I posted in the Speakeasy forum over at DSL Reports. A while later I heard back from a representative at Speakeasy that they released the lock 24 hours after I called in, the next day COVAD released the lock to AT&T and that AT&T had been sitting on it for 3 days at that point and didn’t have it scheduled to be completed until another 2 days had gone by. I waited until the morning after the schedule release date and called in to try to get an expedited install and was told that I could only shave a day off of my install. Once again I was more than a bit ticked as this was not what I was lead to believe would happen. I made a post to the AT&T direct forum over at DSL Reports explaining my woes. A representative for the Dallas dispatch center gave me a call 10 minutes later asking me what would be a good time for me over the next couple of days. I told him I was available anytime if they gave me a 30 minute heads-up. He said he’d get back with me in half an hour or so while he pulled the schedule but indicated he would be able to get me in within the next 48 hours. He called back about an hour later with news that he was able to work me in the next day for a “late morning/early afternoon” install. I was out mowing the lawn at 8:45 when “late morning” rolled around and the tech showed up. I had pre-wired a CAT3 pull from the NID directly to my desk (back when I had Speakeasy) and 2 CAT5e pulls from my desk to where I wanted the STB and an eventual media center PC. It took him about 45 minutes to locate the equipment box about 4 blocks away (instead of being in the ROW, it was in somebody’s yard obstructed from view). He got back to the house at about 9:30 and was out of there by 10:00 AM. All in all it was a painless install once it got scheduled.

The TV service worked great when he left. I noticed that I had a fast internet connection (getting just under the advertised 3Mbps) but that latency in starting to load webpages was horrendous on my Mac. The problem didn’t seem to go away when I used Firefox instead of Safari. However, things were zippy on my iPhone and on work laptops (Dells with WinXP). I chalked it up as something annoying, but that I’d figure it out later and headed into the office. So, I was left with three tasks. Configure my AirPort Extreme base station to work with the AT&T RG, and solve my problems with the Mac. Here is how I addressed each of those.

AirPort Extreme Configuration

I first disconnected my computer’s ethernet connection and connected to the AirPort via wifi and launched the AirPort Utility app. I clicked on my AirPort and clicked the “Manual Setup” button at the bottom. I clicked the “Internet” icon at the top of the window to bring up the Internet settings panel. At the bottom of that panel I set “Connection Sharing” to “Off (Bridge Mode)”  and pressed the “Update” button. I then connected my AirPort extreme to the RG through the WAN port and connected my iMac back to the ethernet. Viola! Everything worked.

Slow Browsing on The iMac

I was having some difficulty with the iMac taking forever to load web pages. I noticed that pages that had a lot of images (and thus required a lot of HTTP requests) took longer than a simple text only page. This led me to believe I had a problem getting to the DNS servers. I was able to ping them just fine. I was left scratching my head. I then opened up System Preferences and went to the Network Preferences. For some reason my iMac had the old IP address of the airport base station specified as the first DNS server and then to fall back to the RG as the secondary. As soon as I cleared that out and pressed “Apply” things got zippy on the Mac. Apparently every DNS request was looking for a server at 10.0.0.1, and once that timed out falling back to 192.168.1.254 (the RG). I don’t know if that manually entered IP address for DNS was my fault or something the AirPort did when I first set it up. Either way it is all back in working order again!

CString temp_str;
sprintf(temp_str.GetBuffer(), "%s", "Longitude");
temp_str.ReleaseBuffer();

• Full system backup (i.e. support bare metal restore)
• Hourly backups of changed files (kept for 24 hours)
• Daily tag of changed files
• Weekly full system backups
• Backup at system shutdown
• Restore selected revision of a file

This system will have two components, the client component that performs the system backup. The second component is a server component. The server will most likely be implemented on a distribution of Linux (perhaps using Ubuntu server as a starting point). I will initially write a client for the Windows operating system (targeting XP first, and then extending with functionality provided by Vista and 7). Eventually a client will be developed that runs on Linux systems using LVM.

As a side note, there a few new tweaks to the blog thanks to playing with jQuery. A few more will be coming in the little while.