REU Summer 2007: Flash Power

As an REU this summer I set out to see if using usb flash memory devices is energy efficient. The majority of my research was conducted on Crossbow Stargates which had a usb 1.1 port. Power consumption was higher than initially anticipated, but compared to other means of reading/writing data, such as transferring data with bluetooth, it is the best. The application and overall purpose of my research was to eventually help Dr. Striegel and others in the future to design a caching algorithm for battery operated embedded systems with a usb port.

My initial work, before power could even be brought into the mix, was to find out data rates of the different usb flash drives. I had initially suspected two variables which would alter the data rates of the usb drives. First, there are several different manufacturers of flash memory. Second, the size of the flash memory. While the first held true, the latter did not. Each manufacturer of usb drive had a predictably better or worse write speed. Size, on the other hand, didn't seem to show any trends either way.

Measuring these data rates was the first problem I was faced with. There wasn't a good portable linux tool for measuring data rates that had all the features I had wanted. I spent some time studying a program called Bonnie, but it just didn't have all the features we needed. I eventually began writing my own program. Some of the initial problems that faced this program was how to eliminate output buffering and input caching. The first problem was eventually solved, but I still have not found a way to bypass the input cache. My test program could vary many parameters based on command line arguments which made it very easy to batch multiple tests together in a script. It also was portable and ran correctly on the ARM based Stargate. This program expanded over time as I wanted to measure different situations.

An interesting thing to note is how much writing at different block sizes effected the total speed. As block sizes increased, the data rates increased significantly and the power consumption dropped. Once a block size of about 32 kB was reached, it had little additional effect.

Once we knew that these devices could read and write data at acceptable rates, we moved on to determining how much power they consumed. I created a Lab View interface for logging data from a Fluke multimeter. This would store all the measurements in a csv file that could easily be loaded into a spreadsheet and manipulated accordingly.

The devices consumed as little as 280 uA all the way up to 80 mA depending on what usb drive it was and what state that drive was in. A device had four different modes. The first two need no explanation: read and write. Third, idle was when a device was not reading or writing but was maintained in a 'ready' position. Finally, suspend mode is a USB devices very low power mode. Suspend mode turned out to be an almost phantom state. It existed in the standard, but there was no way to get a device to enter that state. I spent a good deal of time researching how we could suspend a usb device. It wasn't until we took drastic measurements that it actually became possible.

Getting a usb device to enter suspend mode required kernel modifications as well as modifications to the usbcore and usb host driver. The process currently used is a slow one, but I'm sure it can be optimized by further modifications to the kernel and drivers. I was also concerned about the power cost of performing suspend and resume operations. This turned out to be very small, and unnoticeable for writes smaller than 50 MB. Usb 2.0, the bigger and better older brother to u sb 1.1 had some interesting things about it. All the usb flash drives we had were usb 2.0, but since it is backwards compatible with usb 1.1, we never ran into any problems. Usb 2.0 has a clock speed of 480 Mbps which is 40 times faster than usb 1.1. As expected, the read / write rates went way up while using usb 2.0, but so did the power. It went up by about 2.5 times! Although that seems like a problem, it's not. It actually has less total energy cost to use usb 2.0 because it transfers data so much faster.

I did spend some time looking into using bluetooth to transfer data between stargates. This is a relatively simple process, but bluetooth devices are power hungry and much slower than usb flash drives. This was unfortunate, because we thought there might be some power advantages to using bluetooth devices.