•  
• EDN Europe MAGAZINE
•  
• Free SUBSCRIPTION
• Subscription Renewal
• View Media Kit

• EDN
• EDN Australia
• EDN Asia
• EDN China
• EDN Japan

Networking over power line: Will Next-Generation Technologies Stumble

Power-line networking has so far suffered no shortage of hiccups, yet its compelling promise remains fundamentally untarnished. Do new technologies make notable advances over their predecessors?

AT A GLANCE

Ever-increasing bandwidth requirements couple with vendor consolidation and technology advancements to provide abundant motivation to revisit power-line networking. Ixia’s IxChariot software suite proves capable of tackling both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) tests, in configurations with both single and multiple simultaneous streams. Atheros’ latest IEEE 1901 chip set more than doubles the operating- frequency range of its HomePlug AV (audio/video) predecessors in striving to boost datatransfer speeds. Real-life XAV5001 performance improvements are sometimes slight and sometimes substantial. Unfortunately, these improvements often involve significant data loss in one case.

In a 2007 article, I covered 200-Mbps-grade power-line technologies, which were then relatively new on the scene (Reference 1). The hands-on project examined three incompatible 200- Mbps power-line approaches: the Intellon-led HomePlug AV (audio/video), DS2’s UPA (Universal Powerline Association), and the Panasonic-championed HD-PLC (high-definition power-line communication). It also analyzed earlier-generation, 14-Mbps HomePlug 1.0 and Intellon-proprietary, 85-Mbps HomePlug 1.0 Turbo, along with conventional Category 5e cabling and several variations of 802.11 wireless networking.

Much has changed in four years, during which I’ve periodically revisited multiple iterations of both HomePlug AV silicon and software upgrades (Reference 2). Intellon and Panasonic joined forces in developing the IEEE 1901 standard, which optionally supports HomePlug AV, HD-PLC, or both along with other feature enhancements. Atheros now owns Intellon, and Qualcomm now owns Atheros. DS2, which Marvell has acquired, redirected its technology attention toward the ITU’s (International Telecommunication Union’s) G.hn standard, which broadens the physical-transport options beyond the power grid to coaxial cable and twisted-pair telephone wire. Other acquisitions of power-line pioneers include Broadcom, which acquired Gigle Semiconductor; Sigma Designs, which purchased CopperGate Communications; and STMicroelectronics, which bought Arkados. Meanwhile, Infineon went in the opposite direction, spinning off its networking group into a stand-alone corporate entity, Lantiq (see sidebar “Whither G.hn? Good question”).

So it’s a tempting time to revisit the power-line landscape. Although wireless networking is a natural candidate for untethered mobile-electronics devices, it’s subject to range limitations, interference-induced degradation, and inherent performance shortcomings. Category 5e and coaxial cable—and, to a smaller degree, phone-line wire— deliver abundant bandwidth potential, but they restrict device location, and retrofitting a structure to enhance its wiring topology is time-consuming, expensive, and difficult. These shortcomings in part explain the inherent appeal of power-line networking: Why not take the same power cord you plug into a wall for electricity and use it for LAN and WAN (wide-area-network) connectivity? As you’ll see, however, although power-line technology has made incremental progress from both speed and robustness standpoints, it’s still not a panacea.

BENCHMARK BASICS

I chose open-source Iperf as the benchmark- testing utility of the earlier project (Reference 3). However, I later found that benchmarking projects are “fraught with potential peril” (Reference 4). Specifically, assumptions can heavily influence outcomes. A too narrowly focused choice of equipment, software, and usage model would be meaningful to only a narrow set of readers, whereas a broadly focused set of assumptions would yield a “bewildering plethora of outcome data.” For example, altering just one variable, the TCP (TransmissionControl Protocol) window size, dramatically boosted the measured bandwidth.

Fast-forward four years, and you’ll find that Iperf has inherited other issues. The final 2.x-generation of the program, Version 2.0.5, which you can find on SourceForge, dates from mid-2010. There have been no further developments since, and, because its developers intended it primarily as a Linux application, finding up-to-date precompiled binaries for either Mac OS X or Windows varies from difficult to impossible. Version 2.0.0 of Jperf, the program’s Java-based graphical front end, is even older, dating back to 2008. A reboot of the Iperf project, which the Google Code site hosts, is a new implementation with the goal of a smaller, simpler code base and a library version of the functions that you can use in other programs. Yet iperf3 is still in beta testing, and it’s also not backwardcompatible with iperf2.x.

As a result, I’m now using another common networking-benchmark utility, Ixia’s IxChariot, which has worked out well. I had initially planned to use the company’s freeware Qcheck program, but I ultimately found it too limiting. Qcheck’s maximum data sizes yield tests that are too short to be statistically reliable. Qcheck supports only one TCP or UDP (User Datagram Protocol) stream, but I also wanted to simultaneously send multiple streams between any two network nodes as a way of measuring potentially increased aggregate throughput. Although Qcheck’s TCP results are in the ballpark compared with those of IxChariot, Qcheck’s UDP results significantly undershoot the UDP speeds that IxChariot measures. Qcheck also exposes substantially fewer testing variable dials to tweak, and it lacks scripting support.

IxChariot’s Console utility, a Microsoft Windows application, sets up, manages, and periodically collects data from various tests. Qcheck also uses the companion networknode- resident utility, Ixia’s Endpoint, which runs on Linux, Mac OS X, and Windows. Console comes with more than 100 company-created scripts, and users can both customize and copy scripts. As such, IxChariot has at least as many variables as Iperf—if not more. However, two premade scripts serve well for this project.

Because Console also bundles Endpoint, you can run Console from the same machine that acts as one of the tested network nodes. This combined setup is how I chose to conduct my benchmarking analyses (see sidebar “Head online for testing overtime,” in the Web version of this article at www. edn.com/110623cs). However, according to Michael Githens, lab-programming manager at Ixia, this setup is not optimal for high-performance testing. Using the same CPU resources for both Console and Endpoint means that you may be unable to run either of them at full speed. Console and Endpoint functions are also contending for limited networking-transceiver bandwidth. Alternatively, you can run Endpoint software on two systems, with the Console utility executing on a third computer that communicates with the other two. In that case, the Console-installed PC can also have lower network performance than the others.

“It doesn’t need a high-speed connection, [as the test links do],” Githens says. “It is passing less data; the results come only from the test links, not the management links.”

TEST ENVIRONMENT

My approximately 1300-square-foot geodesic-dome residence dating from the mid-1980s serves as my test bed (Reference 5). Three of the powerline- network nodes I tested were in the approximately 25-foot-diameter downstairs main room, against one wall in a dining-room alcove, in the middle of the room on a stairwell near the entertainment system, and against the opposing wall near the router. Next door to the router is the mud room, containing the fourth power outlet I employed in the testing, as well as the circuit-breaker box. I used another entertainment system in the upstairs bedroom as the fifth power-line node.

Each ac outlet connects to a phase of the 200V power feed, but I didn’t know which phase or which circuit breaker each network node employed. Having this knowledge would have been ideal because jumping across the phases at the circuit-breaker box can produce notably worse power-linenetworking performance than that of network traffic that flows between same-phase outlets. And, when one circuit breaker feeds multiple samephase outlets, they tend to deliver even higher bandwidth.

I employed various measures to minimize the effect of attenuation for these tests. As power-line-networking veterans know, packets don’t pass through either surge protectors or UPSs (uninterruptible power supplies), so I ensured that such devices weren’t between any of the power-line adapters and their associated power outlets.

Injected noise from running motors also kills packets. As a result, even though I normally have noise filters between my refrigerator’s compressor and my home’s furnace fan, neither they nor any other motors were operating when I was logging benchmark results. Using illuminated fluorescent bulbs is also a no-no if power-line-network performance is at a premium. One other noise-generating culprit might be a surprise to some: the switching power supplies in inexpensive ac adapters, battery chargers, and other wall-wartbased and otherwise ac-to-dc-fueled devices, so I unplugged them all before beginning the tests.

Because I was iteratively exercising multiple power outlets as network nodes throughout the house, I used portable computers as Endpoint-executing platforms. Most of my laptops and netbooks, however, contain only 10/100- Mbit Ethernet transceivers—a problem because some of the power-line-networking adapters embed GbE (gigabit- Ethernet) transceivers and claim greater- than-100-Mbps real-life performance. Fortunately, both a first-generation Apple MacBook, running Mac OS 10.5, and a Dell Latitude D420, using Windows XP Professional, offer the necessary 10/100/1000-Mbps Ethernet capabilities. The MacBook sufficed as an Endpoint, and the D420 also acted as a Console test bed after I confirmed through the task manager that simultaneously operating the Console and the Endpoint wouldn’t swamp the Console’s dual-core, 1.2-GHz processor (Figure 1).

ADAPTER CANDIDATES

I have for years run a combination of Netgear single-port XAV2001 and quad-port XAV1004 power-line adapters in my home LAN; the quad-port units integrate a switch. This setup has largely been successful, although I occasionally need to unplug and replug adapters to get them reliably talking to each other again (Figure 2). The XAV1004s are in my living-room- and bedroom-entertainment clusters, and the XAV2001s connect to my router and to a network-accessible Insteon controller with an embedded Webserver function. Thus, I’m simultaneously running power-line-based homeautomation and networking traffic. The power-line-based equipment’s modulation frequency is much lower than that of the networking traffic, however, so they don’t interfere with each other. The XAV1004s and XAV2001s employ third-generation Atheros HomePlug AV silicon in the form of the INT6400 chip set. Testing confirms that they’re both faster and more reliable than the second-generation INT6300 ICs in the Netgear XAV101 power-line-adapter predecessors.

The dining-room network node includes a Windows Vista Ultimatebased Dell XPS M1330 laptop. Through its Windows Media Center capabilities, the laptop (Figure 3) acts as an ATSC (Advanced Television Systems Committee) digital-television-antennaarray- fed PVR (personal video recorder). The XPS M1330 subsequently streams both live broadcasts and timeshifted recordings to the entertainment clusters’ Xbox 360s, which act as Windows Media Center Extenders. The recording payloads, with approximately 20-Mbps bit rates, couple with real-life networking-technology bandwidth limitations, compelling me to construct a complicated networking topology. A dedicated, wide-channel, 5-GHz 802.11n wireless tether currently handles the XPS M1330-to-router span, and the router-to-game-console traffic traverses over HomePlug AV. A second noninterfering, wide-channel, 5-GHz 802.11n beacon combines with a 2.4- GHz 802.11b/g access point to service general-purpose network packets.

I’m now using an ExpressCard-based single-tuner ATSC module in the XPS M1330 for TV reception. However, I’ve always wanted a dual-tuner setup. It would enable me, for example, to record one program while watching another or to watch two broadcast channels at once on two Xbox 360s. Realizing this aspiration would require a more robust laptop-to-router tether. Given that the SiliconDust HDHomeRun tuner I want to use is a stand-alone networked device, I’d also have to account for the equally formidable tuner-to-laptop-transfer-rate demands.

As such, Atheros’ latest AR7400 PLC MAC (media-access-controller)/ PHY (physical)-layer transceiver, with an AR1500 AFE (analog front end)/ line driver, caught my eye. It claims to deliver more than 500-Mbps peak PHY rates—a 2.5-times improvement over alternative HomePlug AV products. It also claims peak PHY rates of 700 Mbps and as much as 350 Mbps of throughput over coaxial cables (Reference 6). Conventional HomePlug AV devices operate over a frequency range of approximately 2 to 28 MHz, minus notch-filter-suppressed bands, to avoid interference with shortwave- radio equipment. The AR7400/ AR1500 combo, conversely, extends the operating-frequency range to the optional IEEE 1901-specified 68-MHz threshold.

This approach is conceptually similar to that of Gigle Networks’ GGL541- based Belkin adapters, which I have used, although the implementations differ somewhat. The GGL541 dynamically selects between a 2- to 28-MHz frequency band for conventional HomePlug AV operation and a 50- to 300-MHz band for the company’s proprietary Mediaxtream technology. The AR7400 chip set, conversely, employs a unified 2- to 68-MHz spectrum swath, minus the notch filters.

The AR7400 chip set can route power-line-networking traffic over the earth-ground connection between adapters instead of using the conventional phase-plus-neutral-wire pair—if a performance or another advantage to doing so exists. As such, its SmartLink implementation is conceptually similar to the ClearPath capabilities that Sigma Designs’ HomePlug AV-plus- G.hn-CG5111-plus-CG5113-chipset arrangement touts (Reference 7). Achieving this silicon potential, however, requires three-prong power-line adapters; by press time, Atheros and its OEM partners could provide only two-prong units (Figure 4). Ethernet wiring also involves concerns: To connect a power-line adapter to either the router or a computer, I employed the 8-foot cables that came with the XAV5001 units, assuming that Netgear had supplied wiring of sufficient quality to avoid hampering the adapters’ performance.

TESTING RESULTS

When I did my benchmarking, I had access only to single-port XAV5001s— not to Netgear’s XAV5004 four-port, AR7400-based IEEE 1901 adapters. So I swapped out my XAV1004 AR6400- based HomePlug AV units for XAV2001 adapters to create an apples-to-apples comparison. The testing results show bandwidth variability—both from one node combination to another and, within a node combination, from one data-flow direction to another (Table 1). Note that the simultaneous transfer of four TCP or UDP streams sometimes delivers higher aggregate bandwidth than does a single-stream protocol.

For testing, I chose the four-stream test supplement to the singlestream base-case test after reviewing past benchmarking projects from SmallNetBuilder, a highly regarded online networking-evaluation site, which also uses IxChariot. Following in SmallNetBuilder’s footsteps, I modified Ixia’s bundled Throughput.scr IxChariot script for both single- and four-stream TCP testing, changing the per-stream test-data payload size from 100 kbytes to 1Mbyte.

Expanding beyond SmallNetBuilder’s TCP-centric approach, I also ran single- and four-stream UDP tests. Four-stream UDP testing employed Ixia’s UDP_Throughput.scr IxChariot script unchanged, whereas I modified UDP_Throughput.scr for single-stream UDP tests to increase the per-stream data-payload size from 730 kbytes to 7.3 Mbytes to lengthen the test’s runtime.

For TCP-focused benchmarking, I successfully initiated tests from the Console system. These tests sent data from the Console-running laptop to the Endpoint-running laptop, and vice versa. Conversely, for UDP-focused benchmarking, I could reliably stream data only from the Console-based laptop to the Endpoint-running laptop, resulting in notably increased time and effort between tests for shuttling systems to various nodes. During all of the tests, I plugged in all five nodes’ power-line adapters, although only the two that connected to the Console and Endpoint laptops and the one tethered to the router were passing any network traffic.

Note the results I obtained when I replaced all of the INT6400-based Netgear XAV2001 HomePlug AV adapters with AR7400-based, IEEE 1901-compatible Netgear XAV5001 alternatives in the same locations and orientations as their predecessors. The XAV5001 adapters occasionally had trouble establishing connection with each other, and, even if they did initially sync up, they’d sometimes drop the handshake a short time later. Both are undesirable scenarios, to which the adapters’ front panels’ red lights would alert me. I would try to mitigate the situation by unplugging and then plugging back in the offending adapters. The XAV2001 predecessors didn’t seem to suffer from this communication breakdown. When the XAV5001s were in sync, however, their performance was impressive—most of the time, at least.

In rerunning all of the tests, I frequently obtained speedier—sometimes dramatically speedier—transfer rates with the XAV5001s than with the XAV2001s. Keep in mind that Table 1 shows only the average throughput across each test’s duration. Each singlenumber test summary omits per-stream average results for four-stream tests; the minimum and maximum per-stream and aggregate transfer rates across the test runtime; the overall transfer-rate pattern spread; and the measured minimum, maximum, average, and spread latency. The IxChariot reports embed all of this information and more. You can download this information in both native Ixia TST (test) and exported HTML (hypertext-markup-language)- format-plus-GIF (graphic-interchange format) from http://briansbrain. wordpress.com.

Table 1 also shows packet-loss results for the quad-stream UDP tests of the XAV5001 adapters. With all other tests, spanning both power-line-adapter technologies, both protocols, and both single- and four-stream test scenarios, source-to-destination data-transfer success rates were consistently greater than 99% and, frequently, 100%. However, in these cases, the packet loss is substantial and repeatable. I reran the tests multiple times over the course of many days. Again, the worst-case stream’s four-stream average loss was sometimes notably higher than that of the four-stream average.

DROPPED-PACKET DIAGNOSIS

I don’t typically share testing results with vendors before an article’s publication, but this case seemed atypical. To ensure that I wasn’t overlooking some fundamental mistake that would unfairly represent Atheros and Netgear’s partnership product, I informed Atheros and Ixia that I had encountered approximately 50 to 75% data loss only in my fourstream UDP tests and only with the AR7400-based adapters. However, I did not provide Atheros with per-test statistics.

Peter Shread, senior manager for PLC-application engineering at Atheros, immediately got on the case, attempting to duplicate my results after first confirming that I was running the latest XAV5001 production-firmware revision. Shread subsequently stated that Atheros could not replicate the packet loss that I had reported. The company tested with a pair of the XAV5001s, as well as a set of AR7400 reference-design adapters, all running the same firmware version I had used. The company set up the test with 20 dB of attenuation between the two adapters and transmitted one, two, four, and six UDP streams. The testers observed less than 1% packet loss, and the streams’ aggregate throughput was approximately 250 Mbps in all cases.

I later received a multipage foil set detailing the company’s testing method and results (Figure 5). In further explaining the test-bed setup, the company performed testing on a clean line with 20 dB of attenuation as well as on a power-line setup to simulate typical in-home loads, according to Shread.

There are a few possible explanations for why my quad-stream UDP testing results differ so radically from those of Atheros. One reason might be that every setup is unique, and the company’s simulation may not encompass some nuance of a real-life setup. Alternatively, although I attempted to squelch both other network traffic and spurious power-grid noise from other devices, perhaps I had overlooked an offending device. Also, in power-linenetworking- equipment testing, results can depend on which power outlet you use in a multiple-outlet cluster and on the orientation of the adapter in the outlet. In my tests, for example, the dining-room node employs a right-sideup adapter residing in the lower outlet of the two-outlet cluster (Figure 4a), whereas all other nodes’ adapters are upside-down and in the upper outlet (Figure 4b).

Another possibility could be that Atheros used different Endpoint and Console computers running different operating systems from those that I used. Alternatively, note that all of the computers on Atheros’ test beds had static IP (Internet Protocol)-address assignments and therefore interconnected using only a switch, whereas my setup employed DHCP (Dynamic Host Configuration Protocol) assignments and therefore interconnected using a power-line-adapter-fed router.

One of the two Endpoint computers in my setup also acts as the Console system, whereas Atheros dedicated a third computer to the Console management- and-monitoring function. And, with Atheros’ setup, IxChariot management traffic ran between the Console and the Endpoint systems over a dedicated Category 5-implemented network (192.168.2.xxx); a second Ethernet adapter in each Endpoint system handled power-line-test-packet flow between them (192.168.200.xxx). In my setup, both test and minimal management traffic flowed over the power-line network.

Using four simultaneously running UDP streams for a power-line adapter, although probably not a common scenario, is by no means infeasible. Consider, for example, the SiliconDust dual-tuner networked-TV receiver, which uses the LAN to connect to a Windows Media Center-based computer. This computer also connects with two Media Center extenders. If both the HDHomeRun and the computer connect to the network using power-line adapters and if both tuners are active at once, two UDP streams’ worth of information flows from the HDHomeRun’s adapter to the computer.

Further, Media Center extenders elsewhere in the home could simultaneously be viewing those two streams or others, such as prerecorded content. In this case, two more streams are flowing in opposite directions through the computer’s power-line adapter. Considering that SiliconDust recently released three- and six-stream networked receiver appliances, my four-stream UDP scenario is looking more mainstream all the time.

Soon after completing benchmark tests, I received two four-port Netgear XAV5001 adapters, so I upgraded the power- line portion of my LAN to AR7400-based adapters—a mix of XAV5001s, replacing the XAV2001s, and XAV- 5004s, replacing the XAV1004s. This setup operated for weeks without glitches, but I haven’t yet tried a usage scenario with more than one UDP stream. I plan to do more testing to find out whether the issue is a tool-set, silicon, or usage shortcoming or some combination of these variables.

WHITHER G.HN? GOOD QUESTION

Sigma Designs last fall had taped out on its CG5111-plus-CG5113 powerline- networking chip set and forecast that first silicon would become available by the end of 2010 (Reference A). As far as I know, the CG511x chip set is the first product to implement the ITU (International Telecommunications Union)-sanctioned G.hn networking standard. Sigma Designs also claims that it supports HomePlug AV (audio/video) and the IEEE 1901 follow-on, thereby enabling it to bridge the divergent standards. The company’s proprietary ClearPath and ClearPath Extreme extensions allow for power-line packet transfer over not only the traditional phase-plus-neutral pair but also optionally instead using the power grid’s earth connection. The extensions also enable simultaneous MIMO (multiple-input/multiple-output) broadcast and reception of multiple signals over multiple ac-wire pairs. Early this year, I became aware of another planned G.hn silicon supplier, Lantiq, the former networking division of Infineon (Reference B). At the 2011 Consumer Electronics Show, Sigma Designs demonstrated initial CG511x silicon, and the company claimed that it hoped its firmware would be stable enough to ship samples to me by the end of February (Reference C). Similarly, Lantiq planned to obtain initial samples of its Xway HN X chip set from its fabrication facility in mid-March. Despite these promises, this article omits both Lantiq and Sigma Designs. According to Michael Weissman, Sigma Designs’ vice president of corporate marketing, the company was unable to provide the CG511x-derived adapters because G.hn-based products still required interoperability testing and other steps. The company instead sent three Motorola-branded adapters employing Sigma Designs’ CG2110 HomePlug AV -only chip set. Similarly, Lantiq was not ready to ship samples as of late April, according to Chano Gómez, director of business development at the company. Sigma Designs’ CG2110 also supports ClearPath, and the Motorola adapters’ three-plug configuration seemingly implements it, so I still plan to test these products. Nonetheless, G.hn was my fundamental motivation for engaging with both Sigma Designs and Lantiq. G.hn supporters are vigorous in their condemnation of HomePlug AV and its IEEE 1901 descendant, as UPA (Universal Powerline Association) backer DS2 had previously been. Yet, until the contenders deliver robust silicon, their words ring hollow. Meanwhile, Atheros and other IC suppliers, in partnership with system OEMs, will produce and sell ever-higher volumes of HomePlug AV and IEEE 1901 products, further increasing the technology’s formidable worldwide dominance. REFERENCES “Sigma Designs Unveils Industry’s First G.hn Chipset,” Sigma Designs, Oct 25, 2010, http://bit.ly/jAmKRf. “Lantiq Introduces Family of Chips Supporting Global ITU-T G.hn Standard for Home Networking Applications,” Lantiq, Jan 3, 2011, http://bit.ly/l5yREK. Ganesh, TS, “G.hn Silicon Emerges from Vaporware Territory,” AnandTech, Feb 2, 2011, http://bit.ly/itL2Mh.

For more information
Apple www.apple.com	Atheros www.atheros.com	Broadcom www.broadcom.com
Dell www.dell.com	Google Code code.google.com	IEEE www.ieee.org
Infineon www.infineon.com	Insteon www.insteon.net	Insteon www.insteon.net
ITU www.itu.int	Ixia www.ixiacom.com	Lantiq www.lantiq.com
Marvell www.marvell.com	Microsoft www.microsoft.com	Motorola www.motorola.com
Netgear www.netgear.com	Panasonic www.panasonic.com	Qualcomm www.qualcomm.com
Sigma Designs www.sigmadesigns.com	SiliconDust www.silicondust.com	SmallNetBuilder www.smallnet builder.com
SourceForge http://sourceforge.net	STMicroelectronics www.st.com	Trendnet www.trendnet.com

REFERENCES

Dipert, Brian, “Home transportation: benchmarking power line, 802.11, and Ethernet,” EDN, Aug 2, 2007, pg 40, http://bit.ly/jw4pI3. Dipert, Brian, “Transporting high-def video broadcasts: Are wireless networks up to the task?” EDN, Aug 20, 2009, pg 24, http://bit.ly/agcp5n. Dugan, J, and Mitch Kutzko, “iPerf,” http://bit.ly/lhvklB. Dipert, Brian, “Power-line network performance over TCP: encouraging retesting,” EDN, Sept 7, 2007, http:// bit.ly/mygE1G. Dipert, Brian, “Thin air: ATSC reception isn’t always easy,” EDN, May 14, 2009, pg 20, http://bit.ly/9Zh0Aa. “PLC,” Qualcomm Atheros, 2010- 2011, http://bit.ly/knxDQv Dipert, Brian, “High-speed, reliable networking over power line: Sigma Designs tries one more time,” EDN, Oct 25, 2010, http://bit.ly/lHoHq5.