Networking over power line: Will next-generation technologies stumble or shine?, part 1

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

Brian Dipert, Senior Technical Editor -- EDN, June 23, 2011

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 (Transmission Control 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 is 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 backward-compatible 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 network-node-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”). 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 nook, 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-line-networking performance than that of network traffic that flows between same-phase outlets. And, when one circuit breaker feeds multiple same-phase 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-wart-based and otherwise ac-to-dc-fueled devices, so I unplugged them all before beginning the tests.


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 home-automation 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 Ultimate-based Dell XPS M1330 laptop. Through its Windows Media Center capabilities, the laptop (Figure 3) acts as an ATSC (Advanced Television Systems Committee) digital-television-antenna-array-fed PVR (personal video recorder). The XPS M1330 subsequently streams both live broadcasts and time-shifted 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.

Click here to continue reading: "Networking over power line: Will next-generation technologies stumble or shine?, part 2."