Home transportation: benchmarking power line, 802.11, and Ethernet
Home networks carrying high-definition video and other large-data payloads need ample bandwidth and consistent performance. Can power-line technology fit the bill for long distances, or must consumers resign themselves to stringing Category 5 cable? And which 802.11 standard will suffice for shorter distances?
By Brian Dipert, Senior Technical Editor -- EDN, August 2, 2007
| AT A GLANCE |
| This article assumes that 802.11 has sufficient range to span one to several rooms but not an entire household, thereby requiring a companion backbone technology, such as Category 5e cabling or power line.Equipment and environment specifics can potentially shackle an otherwise-speedy networking technology; you must understand up-front assumptions to accurately assess benchmark results.Newer approaches' targeting of the UDP (User Datagram Protocol) is evident from my Iperf-generated statistics.Power-line networking has made tangible generational improvements in speed, reach, and inherent reliability.This article exposes why 802.11n's “draft” moniker is still justified, but the technology exhibits tremendous promise. |
|
Sidebars:
Multimedia-home-LAN test bed |
Related : “The missing-persons report” explains why I omitted other networking approaches in this study. “Next-step opportunities” suggests additional measures that you could take to advance the analysis I began with this project. “Results downloads and an additional-reading list” allows you to peruse my report files and screenshots to comprehend my logged data in greater detail, as well as suggests technical references to further cultivate your knowledge. “Share your thoughts,” as its name implies, provides a forum for you to comment on data from this article that you find interesting, as well as to peruse and discuss the observations of your peers. “Test-bed alternatives” recommends other network-performance-testing techniques, if Iperf doesn't work for you. “Truth in marketing” provides more thoughts on the disparity between promoted and real-life-achievable network performance, including one egregious example. |
Most home LANs (local-area networks) today serve simply to share a broadband link or printer; however, the situation is rapidly transforming. Broadband access is evolving beyond its e-mail, text-messaging, and Web-surfing roots into areas such as VOIP (voice over Internet Protocol), videoconferencing, multimedia streaming, and music and video rentals and purchases; today's early-adopter power users are driving these applications. And, once that multimedia content enters the premises, consumers aspire to spread it throughout the home in an interclient fashion (Reference 1). These trends have three fundamental impacts on the home LAN: First, the LAN “footprint” must pervasively extend across the premises. Second, the LAN must deliver sufficient performance to allow multiple clients to simultaneously access it in a bandwidth-intensive fashion without perceived degradation in quality. Third, LAN latency also becomes a critical parameter; delay-sensitive interactive applications, such as Internet telephony, videoconferencing, and online gaming drive the need for low latency.
The tipping point at which the network-performance expectations of a crit-ical mass of consumers will rapidly and dramatically increase is looming on the horizon, and it's often advancing on multiple parallel fronts. From a latency standpoint, for example, look at the booming popularity of VOIP services, such as Skype, and of gaming services, such as Microsoft's Xbox Live and Games for Windows Live and Sony's PlayStation Network. And, speaking of gaming, all three of today's leading consoles—Microsoft's Xbox 360; Sony's PS3; and Nintendo's Wii, which works in conjunction with third-party software—can act as media extenders, decoding and playing content that's housed on and streamed from a computer, NAS (network-attached-storage) box, or some other LAN client (Reference 2).
The emerging multimedia LAN mi-gration served as the root motivation for this hands-on project. This report evaluates various networking-technology alternatives, with the goal of assembling a cost-effective, simple to-assemble, easy-to-operate, robust, and high-performance network.
Aspirations and boundaries
Benchmarking projects such as this one are fraught with potential peril. As I noted in an earlier article, up-front assumptions can heavily influence outcomes (Reference 3). “If I select a combination of equipment, software, and usage-model variables that are too specific, my results would be meaningful to only a narrow set of readers,” I wrote. “Choose a too-broad set of options, on the other hand, and I end up with a bewildering plethora of outcome data.” These statements apply equally well to this report.
The intrinsic performance capabilities of two pieces of equipment can significantly influence the robustness of the network connection between those two pieces of equipment. With a traditional Category 5e-cabling topology, the routing and switching gear that establishes and maintains the connection is an additional notable factor, as is any other equipment on the LAN that might also be contending for network access. And with power-line and wireless networking, the list of potential influencers further broadens. In the case of power-line networking, sources of impressed noise can affect the fundamental robustness of the power grid, and, in the case of wireless networking, transmitter-to-receiver distance, intermediary walls, and other environmental attenuators, along with other wireless devices that inhabit the same portion of broadcast spectrum, can degrade signals.
Although some optimistic 802.11 and UWB (ultrawideband) backers might claim that wireless can be the only networking technology necessary to connect the home, reality often intrudes on this Pollyanna prognosis with pragmatic results. In my case, for example, my approximately 2000-square-foot, single-story property requires four conventional 802.11g access points to ensure a sufficiently pervasive coverage footprint (Reference 4). I suspect that Faraday-cage-creating chicken wire in my walls, a common construction technique of multiple eras and regions, is one key culprit. Granted, the MIMO (multiple-input-multiple-output) antenna configurations in 802.11g-derivative and draft 802.11n equipment reportedly notably stretch a wireless network's reach. But I resisted the urge to do long-distance 802.11 benchmarking, in no small part because I was concerned that the results from such testing from my home-office setting wouldn't broadly apply to other operating environments.
In reaching this decision, I also kept in mind the ever-increasing ISM (industrial/scientific/medical) broadcast-spectrum corruption; nearby neighbors' 802.11 networks and other wireless- broadcast sources, such as microwave ovens, cordless phones, and Bluetooth-inclusive equipment are the causes of this corruption. And a wireless-only network approach is of no direct benefit to LAN gear that doesn't embed a wireless transceiver; an external wireless bridge is a cumbersome and expensive “Band-Aid” in such a case. Instead, referencing the home topology in Reference 4, my wireless testing involved line-of-sight connectivity spanning approximately 10 feet between a laptop in the southwest quadrant of my office and an access point in the room's northeast corner (Figure 1). For the LAN backbone, I compared and contrasted two wire-based approaches: traditional Category 5e cabling in both 100-Mbps and 1-Gbps Ethernet flavors and five variants of power-line-networking technology. The power-line spurs terminated in the swamp-cooler closet and our backyard hut; past analysis has identified both locations as being challenging power-line nodes (Reference 5).
This Web-exclusive sidebar“Multimedia-home-LAN test bed” details the topologies and equipment used in my testing. I relied on the Iperf tool, which aims to measure network performance, as my project's benchmarking foundation. You can find more information on Iperf. Note, however, that, with Iperf, the client is the originating point for the TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) data streams. The Iperf server, conversely, captures and logs the data coming from the client.
All the speeds for the power-line and wireless technologies I describe in this section refer to the peak PHY (physical-layer) rates, which differ from the real-life results that follow. My power-line- network testing began with Netgear's XE102 power-line-to-Ethernet adapters, which Netgear based on Intellon's HomePlug 1.0 14-Mbps transceivers (Figure 2). The XE102s came without a configuration utility, and none were available for download from Netgear's Web site. To examine the XE102s, however, I was able to use software from Belkin's site for the HomePlug 1.0-based F5D4070 as well as the Cogency Connection Manager, an older program from some Maverick Power Systems adapters that I owned. Stepping up performance a notch, at least on paper, is Aztech Systems' 85-Mbps HL105E power-line adapter, which the company also based on Intellon silicon, but, this time, of the proprietary HomePlug 1.0 Turbo variety. The Intellon-supplied PowerPacket utility enabled me to assess the adapters' reported bandwidth capabilities and other characteristics. I had previously upgraded the HomePlug 1.0 Turbo adapters to a firmware version that resolved UPNP (Universal Plug and Play) and other issues I'd initially encountered with them (Reference 6).
Further ratcheting up specified performance to the 200-Mbps threshold, three incompatible technologies vie for consumers' wallet contents. Linksys' PLE200 adapters employ Intellon's HomePlug AV transceivers, whereas Netgear's HDX101 power-line-to-Ethernet products implement DS2-designed technology, and Panasonic's BL-PA100 adapters use the company's internally developed HD-PLC power-line ICs. The three contenders' products all em-bed 100-Mbit Ethernet transceivers. Feel free to draw your own conclusions about the disparity between marketing claims and real-life performance capabilities. Users can configure the DS2-based adapters for TCP, UDP, or no protocol prioritization; I ran tests on them in all three modes. Both the DS2- and HomePlug AV-based products also offer substantial per-service QOS (quality-of-service)-customization capabilities, which I didn't evaluate. The HD-PLC adapters are not user-configurable, but, based on the product specifications, I believe that Panasonic has optimized them for UDP traffic.
With all five power-line alternatives and in response to difficulties encountered with past power-line-networking projects, I first paired the adapters with each other from adjacent power outlets within the same room before moving them to their under-test remote locations in the office, swamp-cooler closet, and hut. The power-line adapters' front-panel LED indicators reported and later testing confirmed that the existing pairings survived the relocations in all cases. In fact, the DS2-based Netgear-adapter pairings resurrected in the remote locations after I upgraded each adapter's firmware. However, somewhat irritatingly, to successfully execute the firmware upgrade, I first needed to temporarily relocate each HDX101 to a location with a direct Category 5 tether to the switch.
The DS2-based adapters, which I had obtained in November 2006, were the only ones for which a firmware upgrade was available. I confirmed with DS2 that this upgrade version enabled the notch filters that protect ham-radio-broadcast-frequency bands from corruption and those that suppress interference with 27-MHz wireless keyboards and mice. Linksys' HomePlug adapters provided notch-filter protection only for the ham-radio bands, and, by press time, I could get no response from Panasonic on the presence or absence of any notch filtering in its HD-PLC adapters. I mention this fact not only because of any potential incompatibility issues with RF devices that might result, but also because active notch filters, which restrict power-line adapters' usable spectrum, tend also to reduce power-line adapters' effective performance.
To initiate my wireless testing, I pulled a Belkin F5D6130 11-Mbps 802.11b access point, from an earlier LAN incarnation, out of my garage inventory (Figure 3). Although a bit dusty, it still worked fine. For 54-Mbps 802.11g, I relied on the Belkin F5D7130 access point that currently populates my wireless LAN, and, for 54-Mbps 802.11a, I powered up an Intel Pro/Wireless 5000 access point that'd I'd previously purchased for $4 from Surplus Computers (Reference 7). (The part's original manufacturer's suggested retail price was $450.) I uncovered one minor issue with the Pro/Wireless 5000: I had to configure Iperf to limit UDP transfers to 50 Mbps or less; otherwise, the access point would lock up, requiring a power cycle to restore normal operation. Similarly, I had to hold UDP transfers through the Belkin F5D6130 wireless access point and the Netgear XE102 HomePlug 1.0 power-line adapter at or below 10 Mbps, but the speed limitation makes more sense in these cases because these products include only 10-Mbps Ethernet transceivers.
Most currently available 248-Mbps draft 802.11n access points and routers employ only the specification's 2.4-GHz frequency band (reference 8 and reference 9). At least two notable, dual-band—2.4- and 5.8-GHz—exceptions exist, however: Apple's Airport Extreme N router, which uses an Atheros Communications chip set, and Buffalo Technology's Wireless-N Nfiniti dual-band gigabit router and access point, which the company built on a Marvell Semiconductor silicon foundation. One key difference between the two products is that, whereas Apple's router includes a three-port, 100-Mbit Category 5 switch and similarly offers a 100-Mbit WAN (wide-area-network) port, the four LAN and one WAN connections on the Buffalo router are all GbE (gigabit-Ethernet)-capable. To test whether this disparity in performance potential would translate to a real-life differential, I disconnected the desktop PC from my LAN and instead connected it to the Apple and Buffalo products' LAN ports, thereby using them as routers versus employing them only as access points, as you can alternatively configure them. One other reason to nit-pick about the Apple router was that, instead of providing a Web-browser-based configuration like the other access points and router I tested, it, like the power-line adapters, required that the user install a stand-alone OS X- and Windows-compatible administrator utility. I prefer the browser-based approach because the interface would be largely unaffected by obsolescence or changes in both operating systems and browsers.
The results
My TCP and UDP tests ran for slightly longer than 10 seconds, and ASCII data-logged bandwidth measurements every second, both at the client and the server. I also captured post-test JPEG screenshots both at the client and the server for TCP test runs and at the client for UDP test runs. For some unknown reason, Iperf didn't reliably generate server-side graphical reports for UDP test runs. All of these files are available for you to download at the Brian's Brain blog.
In sorting through the voluminous amount of data in Table A, you should first focus your attention on the TCP and UDP bandwidth reported at the server. As mentioned, the client generates the data streams, which I included in the table for completeness, and the server receives them; therefore, the server-side data provides the true measure of the intercomputer-communication channel's Category 5, power-line, and wireless capabilities. My impressions of the bandwidth statistics follow. I also welcome your observations and interpretations.
|
The sometimes-substantial bandwidth differential for data flow in one direction versus another surprised me. One notable example is the 48.5-Mbps average bandwidth for TCP transfers from the MacBook to the PowerEdge 400SC through the 100-Mbps switch, compared with a 0.33-Mbps average bandwidth in the opposite direction over the same connection. GbE TCP transfers showed similar degradation in the 400SC-to-MacBook TCP-transfer route. Although I operated each computer as both a client and a server, I didn't swap the computers' locations, so it's difficult to determine how much of this disparity was from the computers themselves and how much was from intermediary equipment or other aspects of the link between them. Nonetheless, I replaced the 16-port 10/100 Netgear switch with an eight-port 10/100/1000 switch from SMC Networks upon completion of my testing.
The significant disparity between TCP and UDP bandwidth and the comparative inconsistency of TCP band-width were also memorable. These results struck me even though I knew from my conceptual understanding of the two protocols' functions—that is, the source-to-destination “handshake” and, if necessary, packet retransmission in the case of TCP versus the absence of both these factors in UDP—that differences would exist (Figure 4). I can now understand why the power-line-networking promoters had been discouraged when, in my earlier online and print write-ups, I'd focused only on TCP-based activities, such as file transfers.
On that note, I was impressed with the generation-to-generation UDP improvements that paced the HomePlug 1.0-to-1.0 Turbo-to-AV-technology transitions (Reference 10). Second- and later-generation power-line approaches have also made tangible improvements in overall robustness; whereas I had great difficulty maintaining a stable connection between the laptop and the desktop PC through the HomePlug 1.0 adapters, a situation I remembered well from past experiments, the other, newer technologies exhibited no irregularity in this regard. None of the 200-Mbps technologies delivered strong results for TCP transfers; the DS2 adapters were the leaders with this protocol.
Conversely, HomePlug AV was the clear power-line winner with UDP, at least in my setup, and by a substantial margin. Look, too, at the three DS2 configuration options: TCP-optimized, UDP-optimized, and no protocol optimization; I'd be curious to hear your thoughts on whether you discern a clear and consistent correlation between the results you expect from the selected configuration option and those I obtained. In comparing the power-line data with that of the wireless alternatives, remember that the power-line spurs were dozens of feet long and encompassed a circuit-breaker-box intermediary, whereas the wireless connections were approximately 10 feet long and within line of sight.
For 802.11n, I was attempting to mate a Broadcom-designed wireless module in my MacBook with routers based on Atheros and Marvell ICs. The predictable immaturity of the draft 802.11n standard is, I think, evident in the results. TCP transfers through the Apple router were faster than those through the Buffalo router, due in part, perhaps, to the fact that the same company makes both the laptop and the former router and, therefore, they have more robust interoperability. However, for UDP transfers, the Buffalo router was notably superior in the achievable bandwidth it supported. The 2.4- and 5.8-GHz results for each router were largely comparable, at least in my 802.11-friendly configuration and environment.
In an alternative situation with polluted 2.4-GHz spectrum, on the other hand, the 5.8-GHz band might deliver demonstrably higher performance—at least at short distances. With all other factors being equal, 5.8-GHz signal strength degrades with distance more rapidly than does the 2.4-GHz signal strength. One other measure of draft 802.11n immaturity is that, after I switched the Apple router to 5.8-GHz mode, Windows' Wireless Network Connection Manager insisted that the laptop was no longer connected to the router, even though Apple's configuration utility and Windows itself in all other respects could still access it.
| References |
|
You can reach Senior Technical Editor Brian Dipert at 1-916-760-0159 or at bdipert@edn.com and www.bdipert.com
|
Multmedia-home-LAN test bed The hardware nexus of my LAN (local-area-network) is a Linksys RV042 router, tethered to 100-Mbps Netgear and 1-Gbps Trendnet switches, all in my office’s southwest corner (Figure A). The RV042 manages two WAN (wide-area-network) connections, a 1.2-Mbps-downstream and approximately 300-kbps-upstream AT&T ADSL link, and a 50/50-Mbps symmetrical-fiber feed from SureWest Communications. Although my testing focused on intra-LAN data transfers, also keep in mind the speed potential of the SureWest WAN connection as you survey my results (Table A). After much research and analysis, I settled on Iperf as my project’s benchmarking foundation. I ran the Java-based GUI (graphical user interface) of the Windows-compiled Version 2.02 executable, which programmer Ted Fines created. To understand my results, you must first comprehend a few critical pieces of Iperf terminology. Normally, you might think of a server as the source of network data, but, with Iperf, the client is the originating point for the TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) data streams. The Iperf server, conversely, captures and logs the data coming from the client. Speaking of clients and servers, I employed a Windows XP SP2-based, owner-upgraded Dell PowerEdge 400SC and a first-generation Windows XP SP2-based, 2-GHz Apple MacBook (reference A and reference B). The MacBook, unlike its subsequent-generation siblings, didn’t come with built-in draft 802.11n support, but I purchased a MacBook-compatible and Broadcom-based draft 802.11n module, Apple part MA688Z/B, from Small Dog Electronics; QuickerTek performed the upgrade surgery on my behalf. I then had an ideal hardware platform for this article, because the MacBook’s revamped wireless subsystem now supports 802.11 a, b, g, and draft n standards and supports the draft n standard in both 2.4- and 5.8-GHz flavors. The laptop also contains a 1-GbE (gigabit-Ethernet) transceiver. Similarly, the PowerEdge 400SC is 1-GbE-capable by virtue of its motherboard-resident Intel Ethernet IC. Throughout my testing, the desktop PC remained tethered through the Category 5 cable to the 100-Mbps or 1-Gbps switch as each test dictated. Conversely, the laptop was the roaming system; it was also directly tethered to the switches for the Category 5 tests. For the 802.11 tests, it was wirelessly connected to the across-the-room access point, which was directly connected to the GbE switch. And, for the power-line tests, it connected through Category 5 cable to a power-line adapter, whose matching adapter on the other end of the power-line spur connected to the GbE switch. To assess any bandwidth variance from data flow in one direction versus another, I operated each computer in both Iperf’s client and server configurations. Regardless of which power-line adapter I was testing at any time, all three adapters—the switch-connected one in my office and the remote ones in the swamp-cooler closet and hut—were active and paired to each other at all times. Click on the Properties button for your computer’s network connection, and you’ll face a bewildering plethora of Windows-driver-configuration options for both wired and wireless adapters (Table B). In striving to emulate the typical LAN user, I generally left all driver settings at their defaults, except when necessary to create certain environmental conditions. For example, I did not enable GbE jumbo-frames support. Similarly, dedicated software programs and entire Web sites exist to assist users in fine-tuning their network parameters, such as MTU (maximum-transmission unit), TCP-receive window, and TTL (time to live). However, I judged such tweaking to be beyond the capabilities and interests of most consumers. I also knew that just as LAN-tailored tweaking can degrade WAN performance, WAN-tailored tweaking can also degrade LAN performance. Therefore, I left these parameters at their Windows defaults. In one exception to my otherwise-hands-off strategy, in both my access points and the MacBook, I enabled Broadcom’s Xpress frame-bursting technology, whose default setting is disabled, because I knew that my 802.11g access points’ chip sets supported the technology. Environmental factors As noted, location-specific and time-varying environmental factors can radically influence your network-performance results, especially for power-line and wireless technologies. After pondering for some time how I might comprehend this reality in my testing, I settled on squelching environmental variables as much as possible for my network topology. Realize, as you analyze my results, therefore, that I strive to present each technology in its best light; real-life results in other settings will likely reveal little upside and, conversely, may exhibit tangible downside compared with my numbers. For example, I disabled 802.11b-backward-compatible modes when testing 802.11g. Similarly and when possible, I disabled 802.11b/g-compatible modes while testing the 2.4-GHz flavor of draft 802.11n, and I disabled the 802.11a-compatible mode when testing draft 802.11n’s 5.8-GHz band. In line with these moves, I also enabled the draft 802.11n routers’ wide-channel modes when such a setting was available. I powered down all other LAN clients, so that they wouldn’t generate spurious network traffic that would adversely affect the communication between the desktop and the laptop computer. I also powered off all 802.11 access points on my LAN, except the one that I was testing. After scanning the neighborhood for other active Wi-Fi networks, which had weak but detectable signal strength on 2.4-GHz channels 1 and 6, I set my wireless equipment under test to use nonoverlapping Channel 11. In addition, I powered off and otherwise avoided using any other ISM (industrial/scientific/medical)-band-based equipment, such as Bluetooth mice, the microwave oven, and my wireless headphones. (My cordless phones are 900-MHz models.) Similarly, while collecting power-line-network data, I did not run the swamp cooler, which was a challenge, because my power-line testing took place in the middle of a hot June day. I also didn’t run any other motor-based equipment, such as a hair dryer or a vacuum cleaner, that might adversely inject random noise into my home’s power grid. I employed only 64-bit WEP (Wired Equivalent Privacy) encryption for wireless communications. Higher grade encryption might slow network performance; conversely, disabling encryption might boost bandwidth but is insecure and therefore not a recommended configuration. All power-line technologies I tested had encryption enabled by default.
B. Dipert, Brian, "Apple: writing the (Mac)Book on laptop design," Jan 3, 2007. |
| AT A GLANCE |
| This article assumes that 802.11 has sufficient range to span one to several rooms but not an entire household, thereby requiring a companion backbone technology, such as Category 5e cabling or power line.Equipment and environment specifics can potentially shackle an otherwise-speedy networking technology; you must understand up-front assumptions to accurately assess benchmark results.Newer approaches' targeting of the UDP (User Datagram Protocol) is evident from my Iperf-generated statistics.Power-line networking has made tangible generational improvements in speed, reach, and inherent reliability.This article exposes why 802.11n's “draft” moniker is still justified, but the technology exhibits tremendous promise. |
|
Sidebars:
Multimedia-home-LAN test bed |
Related : “The missing-persons report” explains why I omitted other networking approaches in this study. “Next-step opportunities” suggests additional measures that you could take to advance the analysis I began with this project. “Results downloads and an additional-reading list” allows you to peruse my report files and screenshots to comprehend my logged data in greater detail, as well as suggests technical references to further cultivate your knowledge. “Share your thoughts,” as its name implies, provides a forum for you to comment on data from this article that you find interesting, as well as to peruse and discuss the observations of your peers. “Test-bed alternatives” recommends other network-performance-testing techniques, if Iperf doesn't work for you. “Truth in marketing” provides more thoughts on the disparity between promoted and real-life-achievable network performance, including one egregious example. |
AT A GLANCE
This article assumes that 802.11 has sufficient range to span one to several rooms but not an entire household, thereby requiring a companion backbone technology, such as Category 5e cabling or power line.Equipment and environment specifics can potentially shackle an otherwise-speedy networking technology; you must understand up-front assumptions to accurately assess benchmark results.Newer approaches' targeting of the UDP (User Datagram Protocol) is evident from my Iperf-generated statistics.Power-line networking has made tangible generational improvements in speed, reach, and inherent reliability.This article exposes why 802.11n's “draft” moniker is still justified, but the technology exhibits tremendous promise.
Sidebars:
Multimedia-home-LAN
test bed
Related:
“The missing-persons report” explains why I omitted other networking approaches in this study.
“Next-step opportunities” suggests additional measures that you could take to advance the analysis I began with this project.
“Results downloads and an additional-reading list” allows you to peruse my report files and screenshots to comprehend my logged data in greater detail, as well as suggests technical references to further cultivate your knowledge.
“Share your thoughts,” as its name implies, provides a forum for you to comment on data from this article that you find interesting, as well as to peruse and discuss the observations of your peers.
“Test-bed alternatives” recommends other network-performance-testing techniques, if Iperf doesn't work for you.
“Truth in marketing” provides more thoughts on the disparity between promoted and real-life-achievable network performance, including one egregious example.
Apple www.apple.com
AT&T www.att.com
Atheros Communications www.atheros.com
Aztech Systems www.aztech.com
Belkin www.belkin.com
Broadcom www.broadcom.com
Buffalo Technology www.buffalotech.com
Dell www.dell.com
DS2 www.ds2.es
Intel www.intel.com
Intellon www.intellon.com
Iperf http://dast.nlanr.net/Projects/Iperf
Linksys (a division of Cisco Systems) www.linksys.com
Marvell Semiconductor www.marvell.com
Microsoft www.microsoft.com
Netgear www.netgear.com
Nintendo www.nintendo.com
Panasonic www.panasonic.com
QuickerTek www.quickertek.com
Skype Ltd www.skype.com
Small Dog Electronics www.smalldog.com
SMC Networks www.smc.com
Sony www.sony.com
SureWest Communications www.surewest.com
Surplus Computers www.surpluscomputers.com
Trendnet www.trendnet.com
-
asgw3.txt;4;15
YvlEfQNDRbBgOkW - 2009-16-9 13:15:00 PDT -
asgw3.txt;4;15
TAOHwjLeklnOehjn - 2009-16-9 13:15:00 PDT -
asgw3.txt;4;15
YdOOvcKEZMx - 2009-16-9 13:15:00 PDT -
I don''t know techno, but I am interested in your article comparing wireless and HomePlug powerline adapters. Most of it flew over my head, but this is my problem and I hope you can help, since I''ve had no help from tech support --
For the background, w have one electrical meter at our residence, two buildings, each with two-sided circuit breaker panels. The powerline adapters work great -- really great -- in each building, but not from one building to the other. Wireless is out of the question -- the wireless in the room barely works, so I don''t think stretching across the yard and through a few concrete walls is an option. We may have to run ethernet, but walking on glass seems like more fun.
I''m (trying to use) Zyxel''s 200mbs Ethernet Adapters (PLA-401). Like I said, great in each building but I can''t get the buildings networked together. Is it possible? I would really appreciate your advice. -- Regards, ML Gerrish
ML Gerrish - 2008-22-2 13:24:00 PST
