Sunday, September 29, 2013

BeagleBone Black Exploration

The BeagleBone Black is an inexpensive ($45 US), ARM processor based hobbyist/developer board that runs Linux. This board is similar to the better known Raspberry Pi, enough so that's it's hard not to compare them. The BBB employs the embedded control oriented Texas Instruments AM3359 Sitara SoC, while the RPi employs the video oriented Broadcom BCM2835. I have both boards, so I'll definitely be comparing them.

I ordered the full BeagleBone Black (Rev A5C) starter kit from Adafruit including the 5V power adapter, prototyping breadboard and backplate and jumper wires, and "cape" PCB. I also recommend a microSD card to boot/install alternative Linux OS distros and a microHDMI cable/adapter and USB keyboard for debugging networking configuration.

BeagleBone Black and ChronoDot RTC on Prototyping Breadboard

The BBB comes standard with Ångström Linux on its onboard 2GB eMMC flash storage. Nod to the BBB over the RPi here. The Raspberry Pi requires a prepared SD flash card to get started.

For my purposes, I immediately loaded Arch Linux ARM onto a microSD card, booted from SD, and installed Arch onto the eMMC. I have to give a lot of credit to the developer(s) who produced the Arch image: it's nicely pre-configured to bring up wired Ethernet and SSH using DHCP. Arch thus allows a completely headless install and configuration. Alas, I messed up static IP configuration and had to attach a display and keyboard to work through it.

During the installation process, I felt motivated to benchmark both the eMMC and my microSD card (ADATA 32GB UHS-I).

Device Read
MB/s
Write
MB/s
2GB eMMC 21.2 3.9
32GB μSD (BBB) 4.3 1.7
32GB μSD (PC USB2) 19.6 19.2

The SD interface is incredibly slow. The same card performs tremendously better on my PC monitor's USB2 adapter. I wouldn't want to run the OS from SD anyway, as reliability is always questionable. The microSD interface is clearly intended primarily as a means to load alternative distros onto the eMMC. Even using an SD card for a data/media filesystem takes a bit of effort.

Once running from the eMMC, the BeagleBone Black feels subjectively quick, certainly quicker than the Raspberry Pi. This is no surprise. The TI Sitara contains a more recent, higher-clocked, superscalar processor core with DDR3 RAM support.

My intended use for the BBB is as an internal network services (DHCP, DNS, NTP) and home automation controller. Like the RPi, the BBB doesn't have a battery backed real-time clock (RTC). I easily added one via the ChronoDot RTC and Lemoneer's excellent guide. The BBB has no lack of I/O and should be awesome for monitoring and control. There are even two dedicated PRU cores for true real-time control. I haven't explored this yet, but the PRUs may eliminate much of the need to attach Arduino microcontrollers a la the Raspberry Pi.

For my purposes, the BBB looks to be solidly better than the RPi. That said, the RPi still has some key advantages. There is a huge Raspberry Pi installed base and community. The RPi camera module is appealing. The RPi is decidedly superior for graphics and especially video tasks like XBMC. At these prices, there's something to be said for having one (or more) of each.

Sunday, September 1, 2013

A Night and a Day on Backup Power

Power Management for Home Computing and Networking


In this installment, I discuss strategies by which computing enthusiasts may reduce power and retain or improve availability of home network services.

TL;DR TBD ;-)

Low Power Computing


There's never been a better time for low power computing. A lot of us are optimizing electricity use, not just because power is expensive, but because we've become mindful of waste. Smartphones, tablets, and ultrabooks use a lot less power than desktop PC setups. Mobile devices train us to be aware of power use. We can't always plug in, and it's inconvenient to plug in, so we optimize and prioritize around battery life. For those of us geeks who run home servers, more networking than a single WiFi router, whole house DVR backends, and home automation, it may be time to apply our power management skills to the home. I have some additional motivation: disruptive power outages that take my home off-grid, ranging from momentarily to minutes, hours, or several days.

On-Demand Battery Backup


I've owned a number of small UPSes from APC and CyberPower. These are a great help for those whose power is less than reliable. For many, this is all the power protection they need. Check out the recent "line-interactive" models with "active PFC". These are typically the best match for modern electronic devices where UPS cost is an issue.

If your equipment is mission-critical, especially sensitive, or you need to run on dirty power (as from a generator), you should be considering a "double conversion on-line" UPS. These units rectify current to charge batteries and feed an inverter that produces stable AC output. On-line UPSes are more expensive and less efficient than their line-interactive counterparts, but they serve their niche.

Generating Electric Power


If you live in remote or disaster-prone area, you may be considering the ability to generate your own power. You may be considering a photovoltaic solar installation even if you live in a center of civilization. Make no mistake, generating reliable AC power is a challenge. Some small or remote installations may be better off sticking to DC power and equipment. I won't write more about DC here, but may blog about in the future if I get around to implementing my dream DC system.

Typically, generating your own power means getting a generator setup that runs on fossil or bio-fuel. Good generators are expensive. Around here, some people spring for whole-house standby generators with automatic control systems and transfer switches. These setups usually run on natural gas or propane and cost $10K USD or more. Many more people have smaller "portable" generators that they backfeed into house power, a manual transfer switch, or just replug equipment into the generator itself. If backfeeding, it's critical to turn main line power off at or before the breaker/fuse box.

My generator is a 6500W (max) tri-fuel (gasoline, natural gas, or propane) unit that cost about $2.5K. It's got electric start, but I need to manually engage the key switch, flip switches in the basement, etc. to bring it on line. The generated AC power isn't very clean. I've seen frequency range from 60-64Hz and voltage from 115-130V. If I had an oscilloscope, I could see the ugliness of the "simulated sine wave" output. AC motors will sometimes vibrate on generator, lights flicker, A/V equipment exhibit audio noise, and cheap UPSes beep and refuse to charge their batteries or pass generator power through.

Real UPSes That Work


I can deal with most of the downsides to dirty, generated power. It's temporary; most things work, just not optimally. UPSes that discharge during the initial outage then refuse to charge or pass generator power are a huge annoyance. You'd have to shutdown, unplug, and replug each piece of equipment on each UPS to switch to generator power, then repeat the process to switch back to the UPS! This somewhat defeats the purpose of having a UPS in the first place. It took me a few years to take the hint and solve the problem.

My solution was to purchase a double conversion UPS with extended runtime battery pack. My critical equipment plugs into this UPS and will continue to run on generator power. Non-critical equipment that would suffer from unexpected outages goes on cheap, line-interactive UPSes. This non-critical equipment either survives short outages or stays off until line power returns.
I went with Tripp Lite instead of APC because the equivalent (SURTA series) APC UPS was literally $400+ more.

Data for a Case Study


So now that you've heard the rambling details of why and how I addressed my problem, here are the specifics from recent testing. This takes us to the title of this lengthy post. I spent the night with the UPS unplugged to see how long it would run my critical equipment. Much of the next day was then spent on generator to 1) ensure batteries would charge and equipment run, and 2) determine how long it would take batteries to charge from 10% to 100%.

Equipment consists of:
  • Comcast Business Class network gateway
  • D-Link DIR-825 running as dedicated firewall/router
  • Asus RT-N66U running as WiFi access point and network switch
  • Raspberry Pi running critical network services and monitoring
  • Thin Mini-ITX Intel "Ivy Bridge" PC running as DVR backend
  • HDHomeRun network-attached dual digital TV tuner
I don't have exact power consumption figures all devices individually or all devices together. The UPS won't guess loads under 100W, so I know this is less than that. My back-of-envelope guesstimate is an average draw of ~60W. The runtime figures bear this out.

The equipment ran for just over 12 hours on battery. I was hoping for closer to 16 hours, but there are optimizations left to try. The UPS batteries charged well from generator while equipment continued to run. During the just over 5 hours it took the batteries to charge from 10% to 100%, there was one 19 second interval where input power went out of spec. The generator kicked up to 64Hz and 130V during this time and engine RPM and generator whine were obviously increased. I have no idea why. Anyway, I'm happy enough with these results.

Power Optimization Tips and Tricks


So, how to get from 12 hours to my goal of ~16 hours on battery? Tripp Lite has a nice calculator. Basically, I need to stay closer to 40W than 60W. To PC gamers that probably sounds impossibly low. Well, good thing I'm not gaming on batteries!

Most obviously, functions can sometimes be consolidated onto a single device. For instance, I'm running a separate firewall/router and WiFi access point. Most home users don't do that. Ah, but there's a method to my madness! During some extended power outages cable internet will go out; not always at first, but eventually power backup goes out at the cable headend too. In these situations I want to be able to "shed" the load of my Comcast gateway and firewall/router. And sometimes I just want to be able to power cycle them without taking down my internal network.

So separating and assigning related services that fail together into power/availability groups is sometimes useful. I have an "internet connectivity" group and a "home networking" group. Now, how to lower overall power use?

My PC-based DVR backend and TV tuners pull a decent amount of power. Yet when it comes down to it, DVRs only need to be powered up when they're being used.

Wake-on-LAN/Timer to the Rescue


Some PC-based equipment simply doesn't need to be fully powered up at all times. Modern PCs can generally be put to sleep (suspended to RAM for reduced power draw and quick resume) or hibernated (suspended to disk for no power draw and slower resume). Failing that, systems can be shutdown and booted back up when needed. This is all possible because modern PCs can keep a trickle of power going to a clock and system/network controllers while the PC is still plugged in.

Think of this like your TV. When the TV is off, it's really in "standby". A sensor and controller are powered and waiting to detect your press of the "on" button on the TV remote.

Let's go back to my PC-based DVR example. If this system drew a lot of power, it might make sense to keep it powered off until it's needed to record or stream content. Since my particular system only pulls 15-45W, it's more convenient to keep it on and immediately available. That equation changes when I'm running from battery. This calls for a little automation:
  1. When line power is available, power on, stay on, and run normally. Done.
  2. When running from battery and the system is idle, set the wakeup timer to just before the next scheduled event. Go to sleep or hibernate.
  3. When the pre-set timer goes off, wake up if sleeping or hibernating.
  4. When receiving a magic network packet, wake up if sleeping or hibernating.
The "magic packet" allows another computer or device to wake or boot an otherwise unavailable system from a standby state on demand. There are a number of utilities available to send magic packets through a manual UI or scripted interface. Some systems also support the ability to wake on keyboard/mouse activity or selective USB activity. These are very cool and underutilized features outside the world of portable PCs.

Power Control Hacks


I also mentioned that I'm running a network-attached digital TV tuner. Logically, this is part of a "DVR" power/availability group. The tuner box only needs to be powered when the DVR backend is recording or streaming live TV. Unfortunately, the tuner box doesn't support power management. It's either plugged in and on, or unplugged and off. Some devices are like this.

A little research shows that the HDHomeRun tuner runs on 5V and under 2A. My PC-based DVR already contains cables that can supply the proper voltage and current! Let's say that I hacked a SATA power cable to provide 5V at 2A to a barrel connector that could be plugged into the tuner. Now (in theory) I have a tuner that can power off and on as the PC sleeps and wakes.

Software/Firmware Power Tuning


Intel, AMD, and the various ARM vendors have gotten pretty good at making the hardware and firmware recognize demand and selectively power up/down functional units and communications buses. This used to be done with software (if at all). Still, there are sometimes power saving drivers to install or driver options to tweak to save a little juice. A blunter approach is to disable (in the BIOS/firmware) or remove devices that aren't needed. Underclocking and/or undervolting CPUs, GPUs, or RAM is also an option.

Consolidation and Virtualization


As I stated before, sometimes combining and consolidation is detrimental to sensible grouping and availability of services. Oftentimes, consolidation is brilliantly appropriate. System and container virtualization can make consolidation even more applicable. Let's say I want to add a software PBX like Asterisk to my mix of services. I could easily install this on the DVR system, preferably under virtualization to isolate it from the DVR system image. The PBX would go up and down as the DVR system wakes and sleeps during outages. That said, my voice-over-IP (VoIP) provider already forwards calls to my cell phone when my PBX is down. This makes the PBX a useful but not critical service. And there are potentially ways to proxy voice service and wake the PBX system on incoming calls.

Roll Credits


If you made it this far, I admire your fortitude. Believe me, I wasn't planning to write such a voluminous tome. As always, questions and comments are welcome via Google+.