Google’s OnHub Router Gets Rough Treatment in Early Reviews
Google announced its OnHub Wi-Fi, Bluetooth, and smarthome router just a couple of weeks ago, and released units to a few reviewers for articles that just appeared. The news is not terrific. (Google says OnHub is available for pre-order, but it’s listed as “out of stock” at its own site, and Amazon offers no purchase options except for third-party sellers, who can’t possibly have units.)
While most reviewers praised the ease of setup, the consensus is that many of OnHub’s features aren’t fully baked or fully implemented. Firmware updates will clearly bring improvements, but some problems may be related to hardware implementation. (For more on its features, see my preview, “Google OnHub Router Aims to Simplify Wi-Fi for Everyone,” 19 August 2015.)
- Even though the OnHub is designed as a smarthome hub — supporting Google’s Weave, industry standards Thread and ZigBee (via 802.15.4), and Bluetooth Smart Ready — there’s no way to use those standards in the units that reviewers received.
- The USB 3.0 port is used only for a hardware-based restore. It can’t yet be used for hard drive or printer sharing.
A touted interference-avoiding feature designed to reduce congestion didn’t work for some reviewers and performed inconsistently for others. This feature also may have a key flaw that no reviewers mentioned but I’ll explain below.
While the OnHub is a simultaneous dual-band router, there’s no provision to set the 2.4 GHz and 5 GHz network names distinctly, as on gear from Apple and other makers. This can be useful for segregating high-throughput devices for video streaming (in 5 GHz) from other gear that just needs consistent and long-range access (in 2.4 GHz).
The OnHub can’t access some features — like seeing which devices are connected and changing its name — via the local network if there’s trouble with its Internet connection. Google loves its cloud, and functionality is compromised when the Internet goes down.
The way in which cables are plugged in bothered reviewers because there’s not much space inside the outer sleeve. The OnHub comes with low-profile cables, but regular cables may not work.
The reviewers who seemingly tested coverage and features the least had the best things to say about the OnHub; those who performed more complete tests were the least impressed.
Mixed Reviews Recommend Watch and Wait — The Wirecutter had the bluntest and most thorough review because the timing was right to put the OnHub through the testing developed for its wireless router buying guide update. (Disclosure: I did an edit of that update, but didn’t work on the OnHub review.)
In particular, The Wirecutter liked the ease of setup, and the capability to allow someone to configure it remotely, useful for getting a family member or technical friend’s help. They wrote about the OnHub:
This AC1900 [600 Mbps plus 1.3 Gbps] router is half as fast at long distance as routers half its price, and its current features are very limited compared to the competition — even compared to what Google advertises. Like Google’s Chromecast, there’s a lot of potential for Google to update the OnHub and pack it full of amazing features in the future. Wait to buy it then, if you must; don’t buy it now.
Other reviewers’ thoughts:
- IDG’s Mike Brown was more measured. He, too, is in the middle of 802.11ac router reviews, and was able to benchmark the OnHub against similar routers in the same circumstances. Brown didn’t like Google’s automatic channel reassignment, which didn’t seem to work at all for The Wirecutter, and he thinks power users will find it maddening. Overall, however, he found even the initial OnHub a good choice for a user who doesn’t want to fiddle with settings.
Ars Technica frankly admitted it didn’t have a battery of routine tests set up, but the OnHub didn’t fare well in a less formal approach. “It was fast enough and seemed stable, but it couldn’t match the performance of a ‘real’ $200 router.”
The Verge had a more upbeat tone. The reviewer found that swapping the OnHub into an existing network with a comparable router resulted in better performance, and it did a good job of filling in dead zones.
The Wall Street Journal was very positive, saying “it blows the AirPort away,” but the reviewer doesn’t describe rigorous tests. Rather, he anecdotally noted that an older laptop worked much better with the OnHub than with his current AirPort Extreme.
Don’t Flip That Channel! — Now, my note about interference avoidance. What I didn’t realize from Google’s announcement was that the OnHub’s 13th antenna and software check for network or signal congestion, and then dynamically switch the OnHub to a new channel without rebooting. There’s a huge problem with this approach. The basic Wi-Fi spec doesn’t let a base station tell a client adapter to change channels.
There is a mechanism to do this that’s part of the 802.11h standard, which was adopted way back in 2004 to allow use of the middle part of the 5 GHz band. The standard incorporates a few ways to back off active usage if radar signals are detected, as the U.S. government uses some of that range in parts of the country. A compromise between the military and the FCC allowed the general public and businesses to overlap so long as there was a way for base stations to avoid interfering. (There’s a dispute about whether base stations at their low power level could even interfere, but the deal was settled years ago.)
One part of the standard — Dynamic Frequency Selection (DFS) — does allow an access point to tell a client to change channels, and coordinates how to time it. This standard is built into all standard Wi-Fi chipsets that are used for client hardware and access points. However, I can’t find any reference to whether DFS is used at all in 2.4 GHz or if it’s used in 5 GHz outside those special channels, numbered 52 to 64 and 100 to 140. Most consumer base stations don’t even offer access to those channels. Any operating system or Wi-Fi chipset that lacks this support for other channels would simply be disconnected. (Thanks to Andrew von Nagy for running down the details!)
In any case, all modern operating systems automatically reconnect to networks with the same network name if they’re unexpectedly disconnected. When the OnHub changes to a new channel, it first disconnects all currently connected devices and then fires up the new set of frequencies. Once that happens, Wi-Fi devices scan and reconnect to the network — or at least, they should.
It’s unclear what happens if you’re in the middle of streaming video, engaged in a download, or using other session-based Internet protocols when the base station does its channel switch. The OnHub allows address reservation, so DHCP-assigned network addresses don’t change when a device disconnects and reconnects, but without that in place, every device could suddenly have a new local address, which would break many “stateful” or persistent Internet connections.
If Google is smart, the OnHub should monitor network traffic, and the congestion switch would occur only during sustained severe degradation or when traffic was extremely light and didn’t include any streaming media. (It could also notify an authorized user when congestion was severe, and suggest this sort of change.) But who knows? It wasn’t tested thoroughly in any of the reviews I saw.
Interim Buying Advice — I haven’t gotten my hands on a review unit yet, so I can’t speak from experience. However, given the clear factual issues plus consistent details from other reviews, Google would need to sort out problems, update firmware, and enable the router’s special wireless and hardware features before I could recommend it instead of an Apple AirPort Extreme ($199 list; $180 at Amazon right now) or Time Capsule ($299/$399), or a less-expensive competing router, like the highly regarded (if ungainly) TP-Link Archer
C7 ($139.99 list, $94 at Amazon now).
How can you write that my two C7s are ugly? Since a firmware upgrade a few days ago, they are even faster and appear even more stable than before. I use one as a router/wifi unit and the other as a wireless bridge into my garage office and they rock. As your mother told you, you need to look for the beauty *inside* the C7 -- this is a unit for a long term, stable relationship. And it's a relatively cheap date!
“The reviewers who seemingly tested coverage and features the least had the best things to say about the OnHub; those who performed more complete tests were the least impressed.”
This correlation is neither unique nor even rare in tech reviewing. ?
Wi-Fi routers are hard, because no two testing spaces are the same, and the RF environment can be totally different literally one second to the next, weekday and weekend, daytime and midnight. This was one of the most extreme ranges of repeating stated features all the way to testing pretty thoroughly…
Thanks for the compilation of reviews Glenn!
I would point out one correction to your analysis. The 802.11h amendment does provide for Channel Switch Announcement from AP to client. Most modern clients implement support for this. I don't know if the Google OnHub implements CSA or not, but it might be worth checking into. It's specified for 5 GHz, mainly for DFS support, but can work in 2.4 GHz too.
Do you have any references? I remember this group doing its work, but I thought it only applied for a limited set of channels and circumstances (the DFS-required ones in the U.S. and some other countries). I've never heard a single vendor discuss it, never seen 802.11h on a spec sheet, and to my knowledge before this never seen a consumer device that announced it.
The flip side is that unless 802.11h is uniformly enabled in the client and operates correctly, it won't help those that aren't. I'm thinking about older hardware, embedded devices (which use standard chipsets, but the 802.11h configuration is settable, from my understanding, not a hard-wired chip settings).
I just did another pass, and there's very little since 2004 that I can find about its implementation and use. I'll update the story to be clearer.
I've heard that Ruckus makes considerable use of this as part of their ChannelFly feature to automatically determine the best channel. They deploy this mainly with telcos and public hotspot providers that support a wide range of mobile clients. My contacts have told me it works well with most clients.
I doubt consumer gear would explicitly state support since it's not a selling feature and most consumers wouldn't know what it was (opportunity to confuse more than upsell). My thinking is that it probably comes baked into the Broadcom chipset firmware itself.
I'll ask for more details.
Thanks for running this down. As we've been discussing on Twitter, there may be widespread support for it, but no vendor (Apple, etc.) seems to note how it works in their implementation or even list it as something they support.
It certainly has had chip and chip-vendor driver support, but there's definitely a place between that and the OS where implementation may not be in place outside of the middle-band 5 GHz frequencies.
I'll update the story as you and I find out more!
There are many clients that support CSAs but whether or not they pay attention to them seems to be a different story. We don't maintain a database of CSA behavior because how STAs act changes from OS to OS version.
While I think there is a time and place for aggressive channel changes, a residence, even an apartment or dorm situation isn't usually one of them.
Channel selection is very important to the performance of a Wi-Fi network, especially in crowded environments that aren't centrally managed or controlled. But, it isn't quite as easy as it would seem.
For example, the common thought process is to make channel decisions based on RF interference. While that sounds good on the surface, the REAL measurement is throughput. The best way to choose a channel is to choose it based on available throughput, not RF interference. The key is to have a system that can calculate throughput VERY quickly. (Insert vendor pitch here) :-)
Great review / comments!
Given the router's handing out the assignments in the first place, it should be capable of reassigning the same LAN IP to each client, barring extreme edge cases like a super nerd using a dynamically spoofed MAC. It's been a common behavior of many routers (wired and wireless alike) for years, though it's certainly possible Google's overlooked it with OnHub.
The DHCP standards also allow clients to request a particular IP address in their request. If the address is available or if it isn't already assigned to a different MAC, the router almost always goes with it. I seriously doubt that that would be a problem.
Correct, but we don't know, is the issue. I'm not assuming it won't, but I can't assume it will; it's an item on the list of things to check.
And no one mentions bufferbloat - undesired latency during times of heavy traffic caused by the router buffering too much data.
A simple trip to DSLReports Speed Test www.dslreports.com/speedtest will determine if the router's buffering too much data.
It makes all our networks slow. Loads of people think that it's "normal" that their network responsiveness goes to the dogs when someone is using the network - but that's wrong. It's just bad firmware.
Solutions are well known. The fq_codel algorithm has been in the Linux kernel for 3 years, and it's creeping into commercial products.
It'd be great to see what you find when you get your hands on the Google OnHub
All tech savvy reviews aside... the question is if the average consumer really cares about maximum speed of their WiFi connection. As long as the router manages to offer a stable and reliable connection to whatever client is connected, the average user will be satisfied. This is what Google probably knows best, otherwise they would not have offered the OnHub as just a router first. When you look at the Google OnHub advertisement the ease of use and reliability are emphasised, not maximum speed. Although at the end the only conclusion that seems viable is if the 200 dollar asking price is justified for an incomplete product...
The issue isn't maximum speed, but rather how well a router maintains consistent performance at necessary rates over a given area. If you're spending $200 for ease of use, but the device can't smoothly stream or leaves dead areas in your house or office compared to another device (which might cost as little as $100 and require more one-time configuration help), that's a tradeoff.
Only two of these embargoed reviews, where the outlets weren't given much time, did exhaustive coverage and throughput testing, and their results were from poor to good compared to similar hardware.
Most people don't need 1 Gbps of throughput! But you probably want to have 100 Mbps at the farthest point of your home or office that doesn't drop in and out.
While being temporarily disconnected during a channel change would be a problem, it's unlikely that a new IP address would contribute to that. Most DHCP servers remember the MAC address of clients for the duration of the lease period, typically 1 day. When a client reconnects to a network (Wifi or wired) the DHCP server would assign the same address to the client as it had the previous time it was on the network. I'd be very surprised if the DHCP software built into the OnHub didn't support that, although it would be easy to test. Simply have several clients connected to it and switch wifi off and on on one of the clients, if it gets the same IP then things are working as they should.
Right now, we don't know, though I agree with you what should happen is that there should be no problem; let's even say it's likely. But it's a pitfall, and we need to see testing results. I'll be testing this when I get one.
I think it's really odd to have a Home Automation hub that can't speak ZWave...
What's Google thinking?
I think the main drawback is the loss of your online privacy. You are effectively giving Google access to your complete network traffic. You have no idea what is being recorded into Google's vast database and with this you are giving the company free reign on everything you or family or guests do. And a record of your MAC address so that they can follow you everywhere else you go with it. Yes, they can do much of that already, but should you really be making it easier for them, and paying for it too?
I wouldn't touch one of my devices to this thing with a thousand metre pole! If one of my friends or family get one of these, I'm staying on the mobile network.