|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: $106 Buy From Amazon
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.
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
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|
|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.
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|
|Maximum Simultaneous Connections||38,376||37,037|
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.