editor's blog
Subscribe Now

Benchmarks for IoT Edge Nodes

If you’ve been in the market for microprocessor benchmarks, then you’re probably familiar with EEMBC. Their most recent benchmark suite, ULPbench, was designed to compare microcontrollers (MCUs) so that purchasers could get a neutral, apples-to-apples view of which MCUs consume the least energy.

That’s all fine and good, but it also establishes a path towards something similar but more inclusive: Internet-of-Things (IoT) edge nodes. These are the units way at the edge of the IoT that fundamentally do three things: measure something, do some minor computation, and then send the data… somewhere. Usually wirelessly.

Something’s got to power these devices, and they may be far-flung, even inaccessible. It’s expensive, although possible, to change batteries in nodes scattered throughout a large farm. It’s impossible to change the battery on a sensor miles down a borehole (without bringing it up, of course). So energy consumption is of critical importance on these small systems.

These systems tend to have four main components: the sensor, an MCU, a radio subsystem, and power management. ULPbench provides an approach that might be useful in this context, except that its focus is solely on the MCU, and as you can see below, the radio is another major consumer of energy.

 IoT_burst_profile.png

(Image courtesy EEMBC)

Additionally, the work profiles used to characterize the energy consumption for an edge node may differ from those used to characterize MCUs more generally.

So EEMBC has embarked on a program to define a benchmark suite for IoT edge nodes. This would entail conjuring up appropriate work profiles for these kinds of devices, some of which might leverage ULPbench, some not.

They refer to these edge nodes as being “sleepy” – they do a bunch of work and then go to sleep, waking at some time in the future to repeat the process. That wake/sleep pattern figures into the overall rate of energy consumption. But you may notice mentions of the fact that, if the systems sleep for too long, then this benchmark may not apply – which might be confusing.

Here’s what’s going on there. The issue isn’t really how long the system sleeps; it’s just that such long-sleep behavior may be more typical of edge nodes that leverage energy harvesting for power. And it’s the energy harvesting, not the sleep time, that’s the problem. So a battery-powered unit with no energy harvesting that sleeps a long time would still be covered by this new benchmark.

“What’s the problem with energy harvesting?” you might ask. Well, they’re measuring how much energy the unit needs by measuring the inflow of current from the power source. That doesn’t work for a unit that powers itself through harvesting. There may well be a good methodology for handling such nodes, but they’re in the vast minority these days, so it’s not the dominant problem. EEMBC is focused on the much more common case of battery-powered nodes.

You can read more in their announcement.

Leave a Reply

featured blogs
Sep 25, 2018
Robots are a hot topic these days. From helping doctors in the operating room to helping survivors of a natural disaster, it'€™s clear that robots are poised to play an important role......
Sep 25, 2018
CDNLive India took place a few weeks ago and we are just trying to catch our breath! If you missed it, I'm going to be posting two cool videos before the weekend with the highlights. Here are two blogs by the veteran blogger Paul McLellan - one on Asynchronous Design and...
Sep 24, 2018
One of the biggest events in the FPGA/SoC ecosystem is the annual Xilinx Developers Forum (XDF). XDF connects software developers and system designers to the deep expertise of Xilinx engineers, partners, and industry leaders. XDF takes place in three locations this year.  Sa...
Sep 21, 2018
  FPGA luminary David Laws has just published a well-researched blog on the Computer History Museum'€™s Web site titled '€œWho invented the Microprocessor?'€ If you'€™re wildly waving your raised hand right now, going '€œOoo, Ooo, Ooo, Call on me!'€ to get ...