Using network standby to lower home/office device power consumption: Part 3 - Embedded.com

Using network standby to lower home/office device power consumption: Part 3

Consider the following real-world example of how low power network standby and advanced power management features can reduce overall system energy consumption:
In this example, only the power of the embedded processor that includes I/O is considered, rather than overall system power. The power in network standby is the main concern – not the significantly higher power required when performing functions such as printing or recording a TV program.

The system under consideration has the following properties, based on a system incorporating a product such as the QorIQ P1022:

  • 1.8 seconds to wake to full operation, including voltage ramp-up and software boot. This assumes a mid-range combination of the 1.07s X-Windows and 1.9s Android wake times [9] and the Window 8 wake from S3 state of 2.0 seconds [8].
  • 1ms per packet to process a packet (based on the assumption of a host with a maximum processing rate of up to 1 million packets per second).
  • 300mW SoC power dissipation when in network standby mode at room temperature (25C junction temperature).
  • 5W SoC power dissipation when active and running typical code, 65C junction temperature.

In an otherwise idle network, packets, regardless of whether they require response or not, are assumed to arrive every 80ms. This is equal to the 12.5 packets per second that S Gobriel et. al measured [2].

Packets that require response arrive on average every 3s, but only require response every 60s (these values are protocol and network-dependent, but represent realistic assumptions).

Packets that cannot be responded to by an autorespond proxy arrive relatively rarely, less often than once every 60 seconds, and in the context of an autorespond proxy, such a distinction can be ignored from an average system power consumption perspective.

In a legacy system that does not implement either packet classification or packet accumulation, the system would never be able to spend any meaningful time in a deep sleep mode. This is because the time to wake (1.8s) is significantly longer than the time between arrival of packets (80ms). On average, each time the system enters deep sleep, it would be in deep sleep for only 40ms (half the average packet arrival rate), and it would be awake for at least 1.8s. Therefore the average power required to maintain network standby would be equal to the max power, namely 5W.

In a system implementing packet classification but not packet accumulation (such as the MPC8536E Communications Processor [7]), the system would wake on every interesting packet (on average every 3s), and would be awake for the time to boot plus the time to process one packet. This is a period of (1.8s + 1ms) every 3s. Therefore the average power required to maintain network standby with packet classification would be

Pave = tactive /ttotal x Pactive + (ttotal – tactive )/ttotal x Pns  (Eq. 1)

Where:
   Pave = average power in a given time period ttotal.
   Pactive = power consumption when in active mode.
   Pns = power consumption when in network standby mode.
   tactive = time during ttotal when in active mode (not in network standby), or in the process of waking into this mode.
   ttotal = total length of the time period under consideration.

Using Eq. 1, the power dissipated in a system with packet classification but not packet accumulation is:

   (1.8s + 1ms)/3s x 5W + (3s – 1.8s – 1ms)/3s x 300mW

   = .60 x 5W + .40 x 300mW
   = 3.12W.

This is summarized in Table 1 , below.

In a system implementing both packet classification and packet accumulation (such as [10]), the system would wake every 60s in order to respond to packets before the worst-case 60 second timeout. On average, 20 packets requiring response would have arrived in that time. In this system, tactive then reduces to 1.8s + 20 x 1ms, which is the time to wake up plus the time when in active.

Therefore, using Eq. 1 once again, the average power required to maintain network standby with both packet classification and packet accumulation would be:

   (1.8s + 20 x 1ms)/60s x 5W + (60s – 1.8s – 20 x 1ms)/60s x 300mW
   = .03 x 5W + .97 x 300mW
   = 0.44W.

In a system that utilizes an autorespond proxy, for the workload stated here the system can remain in a network standby state the entire time. In other words, the system need never enter the active state for any typical network packet processing. For the QorIQ T1042 [20], when in the network standby state the power consumed with the autorespond proxy active is typically 150mW. Thus, this is also the average power consumption of a system with an autorespond proxy.

Table 1: Average power consumption for various network standby techniques

When to Use Each Technique
The system described above is anexample system and the relative merits of packet classification, packetaccumulation, and autorespond proxies will not necessarily apply to allsystems. However, there are some generic recommendations that can bemade for when to use each technique:

First, given that there isno mode in which the power of a legacy system is less than the power of asystem with packet classification, packet classification should alwaysbe performed. Waking only on interesting packets rather than allincoming packets is a relatively small amount of additional hardwarecomplexity, and is recommended.

Similarly, the incrementalhardware and software complexity to support packet accumulation as wellas packet classification can also be recommended in general. Separatestudies may be done in the future on the optimal number of packets orsizes of buffers to support for packet accumulation, but in its simplestand most minimal form, packet accumulation utilizes memory that existsin a system with packet classification for other purposes. This memorymay exist to store the system context for waking from the networkstandby mode, or it may simply be the size of memories required toreceive a maximum-sized Ethernet jumbo frame on the order of 9000 bytes.In such a case the incremental power to support packet accumulationrather than simply packet classification may be negligible, and thuspacket classification with packet accumulation can be broadlyrecommended.

For applications on small networks where networkconnectivity messages are expected to be infrequent, the simplerapproach of packet classification combined with packet accumulation maybe preferable as it can lead to slightly lower system cost and power.However, in most cases the power and cost issues are minimally impactedwhen implementing autorespond proxy capabilities.

Even in thecases where packet classification and accumulation are acceptable, overtime most commercially available NICs and SOCs will likely adopt theautorespond proxy due to its general purpose nature. Hence anautorespond proxy is the best general purpose solution, particularlywhen the power saving over the life of the product is considered.

Conclusion
Designersare challenged to continually increase product performance in embeddedand networked applications for home and office while adhering toconstantly shrinking energy budgets.

Within the cyclical statesof the embedded networked application, there are three techniques forlow power network standby. Packet classification saves power by allowingsystems to parse and drop packets that do not need to be responded to.Packet accumulation extends the time the system can remain in thenetwork standby state by buffering packets for response at a later pointin time. An Autorespond Proxy provides separate hardware to respond tocommon packet types without waking the system.

Going forward, theincreasingly stringent government regulations and public demandultimately will require network standby to approach 0 W. The challengewill be to further innovate and reduce network standby power.

Part 1: The cyclical states of embedded systems
Part 2: Techniques for low power network standby

Ben Eckermann is a Senior Member of Technical Staff, and Systems Architect forDigital Networking at Freescale. He has designed and architectedlow-power products for Freescale (and formerly Motorola) for more than12 years. He holds a Bachelor of Engineering (Computer Systems) withFirst Class Honours from the University of Adelaide, Australia.

Ron Huff is Senior Product Manager for Digital Networking at Freescale. Ron is currently managing several Freescale QorIQ Network Processor products. Lately he has been leading low power initiatives in the Digital Networking group including the low power network presence capabilities of the T1042. During his 13 years at Freescale and formally Motorola, he has also worked in a variety product management roles in the Automotive, Cellular and the Application Processor groups. He holds a Bachelor of Engineering (Electrical) from the University of California, Los Angeles.

References

1.S. Nedevschi, J. Chandrashekar, J. Liu, B. Nordman, S. Ratnasamy, andN. Taft, “Skilled in the art of being idle: Reducing energy waste innetworked systems,” USENIX Symposium on Networked Systems Design andImplementation (NSDI), 2009.

2. S. Gobriel, C. Maciocco, T. C.Tai, “Long Idle: Making Idle Networks Quiet for PlatformEnergy-Efficiency,” International Conference on Systems and NetworksCommunications (ICSNC), 2010.

3. Y. Agarwal, S. Hodges, J. Scott,R. Chandra, P. Bahl, and R. Gupta, “Somniloquy: Augmenting NetworkInterfaces to Reduce PC Energy Usage,” USENIX Symposium on NetworkedSystems Design & Implementation (NSDI), 2009.

4. IEEE, “IEEEStandard 802 Part 3, Amendment 5: Media Access Control Parameters,Physical Layers, and Management Parameters for Energy-EfficientEthernet“, IEEE Standard 802.3az, 2010.

5. Frequency dependenceon leakage: K. Roy et al., “Leakage current mechanisms and leakagereduction techniques in deep-submicrometer CMOS circuits,” Proc. IEEE,vol. 91, no. 2, pp. 305–327, Feb. 2003.

6. D. Plummer, “An Ethernet Address Resolution Protocol,” IETF RFC-826, November 1982.

7. “MPC8536E PowerQUICC IIITM Integrated Processor Reference Manual”, Freescale Semiconductor, MPC8536ERM Rev1, 2009.

8. Windows Hardware Certification Requirements for Client and Server Systems .

9. Lineo Warp Website, Products and Services – Warp .

10. “P1013/P1022 Fact Sheet”, Freescale, QP1022FS Rev1, 2011.

11. ENERGY STAR specification, ENERGY STAR Program Requirements for Computers , Version 5.0.

12. Microsoft, “Network Driver Interface Specifications (NDIS),” Version 6.20.

13. B. Combs, “Network Power Management for Windows 7,” Microsoft Windows Driver Developer Conference, 2008.

14. ECMA standard, Proxzzzy for sleeping hosts , ECMA-393, February 2010.

15. K.Sabhanatarajan, A. Gorden-Ross, M. Oden, M. Navada, and A. George,“Smart-NICs: Power Proxying for Reduced Power Consumption in NetworkEdge Devices,” IEEE Computer Society Annual Symposium on VLSI (ISVLSI),2008.

16. M. Gupta and S. Singh, “Greening of the Internet,” ACM SIGCOMM, Karlsruhe, Germany. August 2003.

17. S. Nedevschi, L. Popa, G. Iannaccone, S. Ratnasamy, and D. Wetherall,“Reducing network energy consumption via sleeping and rate adaptation,”USENIX Symposium on Networked Systems Design & Implementation(NSDI), 2008.

18.  W. Heinzelman, A. Chandrakasan, and H.Balakrishnan, “Energy-Efficient Communication Protocol forWirelessMicrosensor Networks”, Proc. 33rd Hawaii Int. Conf. System Sciences(HICSS), Maui, HI, Jan. 2000.

19.  J. Shafer and S. Rixner, “AReconfigurable and Programmable Gigabit Ethernet Network InterfaceCard,” Technical report TREE0611, Department of Electrical and ComputerEngineering, Rice University, December 2006.

20.  “ QorIQ AMP Series T1042 Communications Processors”, Freescale, AMPT1042PFS REV 0

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.