At a glance | |
---|---|
Product | TP-LINK Google OnHub Router (TGR1900) [Website] |
Summary | Extremely dumbed-down AC1900 class router built by TP-LINK and powered by a Google OS. |
Pros | • Dedicated dual-band monitor radio |
Cons | • Extremely limited feature set • Must be logged into a Google account to administrate |
Typical Price: $48 Buy From Amazon
Introduction
Update 1/19/16: Corrected routing throughput
Shortly before our original review of TP-LINK’s Google OnHub, Google reached out to discuss what they could do to help us do a better job of testing the OnHub. As you know, Google provides a very simple set of controls for configuring OnHub, so we were not able run some of our router test benchmarks. And for the tests we could run, we couldn’t run them as we normally do.
So for this retest, Google provided an OnHub loaded with a special test firmware that enabled command-line controls that were used to configure the OnHub like all other routers we test. Google assured me the special firmware is identical in all other aspects to OnHub’s first 7390.62.2 firmware update your OnHub should have already automatically downloaded by now.
The 7390.62.2 release notes don’t provide a lot of detail, but mentions a few tweaks aimed at improving wireless performance.
Release notes
The original review mentioned problems with viewing the network configuration. Those problems continue. It still takes awhile for devices to appear (and leave) the network list. The left screenshot below shows the Windows 8 AcerAspireS7 device shown twice. I took the shot while drag-and-dropping a large file. You see one of the instances showing bandwidth usage while the other doesn’t.
When I transferred the same file using the x220i device (Lenovo x220i running Win 7 Home Premium), bandwidth use was never shown.
OnHub network detail
Priority Device
I tried out the Priority device feature, since I didn’t do it last time. I initiallly connected a 10/100 switch to the OnHub’s LAN port, then plugged in the two Windows laptops described above. I was able to connect the Windows 7 (x220i) system to a share on another Windows 7 machine on the OnHub’s WAN side, using UNC notation (\\10.168.3.100). (The OnHub WAN port was connected to my normal LAN.) But the Windows 8 machine refused to connect. Oddly, when I unplugged the Win 8 machine (AcerAspireS7) and connected it to the OnHub via Wi-Fi, I was able to connect to the WAN-side share.
Setting the priority device is easy, as shown in the screenshot below. Just tap the icon in the bottom right corner of the Network screen (highlighted above) and the screen below opens. Your only time choices are 1, 2 and 4 hours, but you can end a device’s priority early or change the time period.
Setting the Priority device
Once the two systems were connected, Android device was selected as the Priority device. This is the Dell Venue 7 tablet running the OnHub app. Drag-and-drop file copies from WAN to LAN were started on both devices, creating downlink traffic. Making either device the Priority device in this case had no effect on transfer rate.
So I deleted the file from the WAN system, created duplicates of the same file (using different names) on x220i and AcerAspireS7 and started drag-and-drop transfers to the WAN-side machine, creating uplink traffic. This time device priority was clearly evident. The table below shows the x220i and AcerAspireS7 getting the higher throughput share as soon as it was made the Priority device.
Transfer Device | Priority Device | ||
---|---|---|---|
Android device | AcerAspireS7 | x220i | |
x220i | 170 k | 330 k | 6+ M |
AcerAspireS7 | 350 k | 22 M | 355 k |
File transfer throughput (Bytes/s)
Windows 7 doesn’t show the handy file transfer plot that Win 8 does and it appears to average throughput differently. The x220i’s file transfer window showed a slow, constant transfer rate increase instead of an instant jump when it was made the Priority device. So the actual transfer rate was probably much faster than the 6+ MB/s shown in the table.
Routing Performance
Update 1/19/16: Corrected routing throughput table values. Data entry error
Google fixed the spontaneous reboot bug I found last time with port range forwarding. So this time, I was able to open ports 1 – 65535 so that IxChariot could do its thing for WAN-to-LAN testing, using our standard router test process. The table below summarizes the results and includes the original results for comparison. Performance is comparable to other current-generation routers.
Test Description | TP-LINK OnHub (retest) | TP-LINK OnHub (original) |
---|---|---|
WAN – LAN | 683 | – |
LAN – WAN | 731 | 817 |
Total Simultaneous | 1,332 | – |
Maximum Simultaneous Connections | 38,376 | 37,037 |
Firmware Version | 7390.62.2 | 7077.122.4 |
Routing throughput
The IxChariot unidirectional composite plot below shows periodic spikes up to peak speeds near 950 Mbps for uplink and 910 Mbps for down.
Routing throughput unidirectional summary
The simultaneous up/downlink benchmark plot shows lower throughput in the first 10 seconds or so, which is an IxChariot quirk. Once that settles down, the usual pattern of higher uplink than downlink throughput that is typical of our test methodology is evident.
Routing throughput bidirectional summary
Wireless Performance
The OnHub was tested using our V8 Wireless test process. Through the controls Google provided, I was able to set the OnHub to Channel 6 and 20 MHz bandwidth mode for 2.4 GHz and Channel 153 and 80 MHz bandwidth mode for 5 GHz. The test client was connected using WPA2/AES encryption.
As before, OnHub was centered on the test chamber turntable, with the front of the router facing the chamber antennas for the 0° position. This time the outer cover was left on during testing.
TP-LINK Google OnHub Retest – chamber
The retest Benchmark Summary below compares the average of throughput measurements made in all test locations from the retest (left) and original (right) tests. There wasn’t much change in average throughput for either band.
TP-LINK Google OnHub Retest Benchmark Summary
For the throughput vs. attenuation profile comparison, I mixed things up a bit from the original review. This time the NETGEAR R7000 and lower-ranked TRENDnet TEW-818DRU and ASUS RT-AC68P are compared. The original plots are available in the previous review.
2.4 GHz downlink shows the OnHub (TGR1900) at the bottom of the pack, below even the TRENDnet TEW-818DRU that ranks just above it in the Router Ranker.
2.4 GHz Downlink Throughput vs. Attenuation
The 2.4 GHz uplink plot shows a tighter grouping for the four products. This time the OnHub does slightly better than the ASUS RT-AC68P from 27 dB onward.
2.4 GHz Uplink Throughput vs. Attenuation
The 5 GHz downlink test summary leaves no question as to the positions of each product. The OnHub once again comes in at the bottom of the compared group.
5 GHz Downlink Throughput vs. Attenuation
The 5 GHz uplink plot again has the products tracking more closely. The OnHub is the lowest line for the entire plotted range, closely tracking the TRENDnet for most of the tested range, with the ASUS joining at 18 dB onward.
5 GHz Uplink Throughput vs. Attenuation
Closing Thoughts
The Router Ranker once again places the TP-LINK Google OnHub in last place, this time at #12 out of 12 AC1900 class routers tested. The Ranker Performance Summary shows the 2.4 GHz range sub-ranks probably contributed to the bottom rank, since neither uplink nor downlink made it to the 54 dB test used for this sub-ranking.
Router Ranking Performance Summary
Since Google said their tests showed the TP-LINK OnHub "compar[ing] favorably to competitive solutions" in open air in-home testing, I ran additional tests in both bands. But each time, the results were consistent.
So if you’ve got a TP-LINK OnHub and have noticed improved wireless performance with the new firmware, please let us know in the Forums using the link below or via [email protected]. But our bottom line on the TP-LINK OnHub remains the same: nice to look at; meh wireless performance; and a minimalist feature set for folks who just want to plug something in and get their Wi-Fi mojo working.