For many years I had servers running in my home office. They hosted a work-in-progress software project, a few low volume open source projects, and family websites. Mid 2008 I started testing Amazon’s EC2 service, and within a few weeks I had moved all of my home servers to EC2. Overall, my experience with EC2 has been great. Very little down-time, good connectivity, extreme flexibility, and decent prices.

The primary benefit of on-demand servers is, of course, compute power (and cost) only when you need it. For my own software project I start and stop servers to run demos on a regular basis. When I am not giving a  demo, I turn off several servers and therefore stop paying for them.

Alternatives

Although I like EC2, I remain open to alternatives. I have looked into Linode, Slicehost (before being purchased), and others. Until recently, I have not felt compelled to try any of them. After reading Jay Kuri’s nice comparison of Rackspace’s Cloud Servers (CS) and Amazon’s EC2, however, I decided to give CS a try. I tested CS for several days, and this is what I’ve concluded:

CS Positives

1. Jay’s assessment of the price/performance lead for CS seemed right-on. I launched several 1024MB / 40GB instances running the same OS and version as my EC2 small instances (different kernels however). For about half the hourly cost, the Rackspace instances performed nearly twice as fast in most tests. Granted, my tests were not exhaustive and the CS instances could have landed on under utilized hardware several times (where they are allowed to burst above the guaranteed minimums). But even on busy hardware, the performance of non memory constrained CS 1024MB / 40GB instances seems likely to be as good or better than EC2 small instance. For half the cash.

2. Rackspace’s CS service is very simple to use. By comparison EC2 is far more complex (AMIs, AKIs, and ARIs! Oh my!). If you don’t need all of EC2’s features, the clean design of CS is great. With CS you select a distro by name and click a button. In a few seconds you have a running instance with a public static IP address, a private static IP address, and persistent local storage. No volumes to mount, IP addresses to assign, security groups to tweak, or keypairs to generate. Once running, creating a full instance backup and launching additional copies from that backup is extremely easy. No documentation needed.

3. Rackspace lets you configure reverse DNS for public IP addresses. This makes sending email from CS instances workable. If you try sending email from EC2 instances you will quickly learn that some ISPs just block it as spam; due in-part to the lack of configurable reverse DNS for elastic IP addresses.

4. I actually chatted on-line with a human service rep. who was knowledgeable and friendly. With EC2 you must pay extra for that kind of service. Without paid support, you will post to an Amazon forum and wait for a response. Rackspace CS support seems to be just like their full hosting service’s support. This is great for now, although I do wonder if they will be able to maintain that level of support in what I’d assume is a lower margin business.

CS Negatives

1. There is no mountable persistent storage like Amazon’s EBS. The lack of mountable storage makes it more challenging to add and remove stateful servers on demand. For example, I have a database server that only runs when I am giving demos of my project. When the server isn’t running, the database state still persists on an inexpensive EBS volume.

Rackspace highlights the fact that their instances have persistent local storage by default. This does simplify initial configuration a bit, but their implementation has a major drawback: Once you allocate an instance on CS — and start paying for it — you can’t turn it off without losing its “persistent” storage. Sure you can “shutdown -h now” the OS, but as far as Rackspace is concerned the instance remains active and can be rebooted. You continue paying for the instance because they don’t release its resources.

If you want to stop paying for an instance, you must fully delete it. When you delete a CS instance, say goodbye to its persistent storage and all “backups” you’ve made of that instance. Yes, they automatically delete your backups! What Rackspace calls a backup is probably just a VM snapshot that is bound to the VM itself.

There are workarounds. One could backup an instance’s data to Rackspace Cloud Files before deleting it, use a mounted NFS drive from another instance that will remain active, find a fuse filesystem to mount Cloud File drives, etc. I looked into most of those options in the pre-EBS days at Amazon and decided to pass. The situation is a bit nicer under CS since you always control when the storage goes away, but in the end I’d prefer to keep full backups for disaster recovery rather than starting and stopping instances.

Another big problem caused by the lack of mountable storage is that you can only obtain more disk space by allocating larger more expensive instances. If you need more disk space, you must pay for additional RAM, computing power, and a fixed size disk upgrade. For example, if you need 81GB of storage you must pay for a rather large instance that also has 4GB of RAM and costs twice as much to run as an instance with 80GB of storage.

2. No public server images. If you don’t like the OS choices that CS offers, you are out of luck. Even if you just want to start with a tweaked version of a stock OS, you are out of luck. Under EC2, for example, I really like the work Alestic has done in creating customized Debian and Ubuntu images that everyone can use.

3. The Rackspace CS user community is either much smaller or less active than EC2’s. The online forums are empty in comparison to the EC2 user forums. If Rackspace does eventually enable public images, I’m fairly sure there will be far fewer choices than on Amazon. At least for a while.

4. Rackspace is lacking many other supporting features and services that Amazon provides. I don’t yet need most of these myself, so this is not a strong negative. But I may eventually take advantage of security groups, load balancing, hadoop, or the queuing service. You can install similar software packages on CS instances manually, but that’s more work and the Amazon prices are generally good.

Summary

Amazon EC2 is a deeper, more flexible, and complex service. EC2’s unique features and design leads me to believe that Amazon invented everything from scratch short of the hypervisor and operating systems. Rackspace CS gives you more computing power per penny and is easier to use. The simple but limited CS feature set gives the impression that Rackspace/Slicehost put a nice web UI atop Citrix XenServer.

I will be sticking with EC2. For my needs, the lack of mountable storage under CS is a deal-breaker. Rackspace’s local storage is primarily a convenience for situations where the underlying physical hardware crashes irrecoverably. Without mountable storage, CS is best suited for either replacing physical machines that are never turned off or for stateless nodes.

But Rackspace looks to be catching up with Amazon. If they grow a few key features I would reconsider using CS. It is hard to ignore the cost and performance advantages of the smaller CS instances that I tested.

NOTE: I chatted with a Rackspace rep. who said you’d eventually be able to store backups within Rackspace Cloud Files independent from instances. The rep. didn’t know when that would happen. While that will be an improvement, the backups will remain copies of the entire instance; state, OS, apps, and all. There will still be no direct way to preserve your state and OS logic separately, and still no way to add storage capacity incrementally.

AVR Bootloader Faq

Table of Contents

1. How do I get started?
2. What are the NRWW and RWW regions?
3. How does the bootloader update the application?
4. Can a bootloader update fuses?
5. What is BOOTLOADER_SECTION in <avr/boot.h> for?
6. How do I program the bootloader to the MCU?
7. How do I program both the application and the bootloader?
8. Can a bootloader use interrupts?
9. Should the bootloader or the application run first?
10. How does the bootloader know when to start the application?
11. How does the bootloader start the application?
12. How can the bootloader be sure the application is intact?
13. Can the bootloader use code built into the application?
14. Can the application use code built into the bootloader?
15. Why can’t global variables be accessed from shared functions?
16. Can the application use an IRS built into the bootloader?
17. How can a shared ISR access global data?
18. Can I save space in a bootloader with few or no ISRs?

This FAQ was also posted as a tutorial on avrfreaks.net