Results: PerformanceTest 7 Graphs
Why you can trust Tom's Hardware Our expert reviewers spend hours testing and comparing products and services so you can choose the best for you. Find out more about how we test.
One of the things we love about PT7 is its data graphs. Now that we’ve seen the raw comparative results on the previous two pages, we want to look a little deeper into the data to show throughput over time. That said, we don’t want to get exhaustive and boring, so we’re going to cherry pick our results in order to illustrate points rather than be overly redundant.
To begin, let’s look at the effect of distance on our AirLive router under 2.4 GHz TCP traffic. Ideally, you want to see a straight line, signaling that throughput isn’t getting hammered by interference and traffic is moving smoothly. With more distance and obstacles, the propensity to see drop-outs in the chart increases. Thanks to its beamforming, the AirLive does a very respectable job and shows minimal erratic behavior in the second chart.
When we switch to 5.0 GHz for the same TCP tests, we see a much different and less expected story. Our same-room test with the AirLive looks blissfully even, although we see throughput take a sudden jump about 45 seconds into testing. This might signal something like a piece of interfering equipment suddenly turning off. While we ran our tests in fairly static conditions, we still saw such plateau hopping repeatedly in our test results across vendors.
Throughput hopping aside, look at our distance test results. What looks like a fair 57.6 Mb/s on our bar chart looks more like a manic disaster here. Throughput ranges from almost 80 Mb/s down to 0 Mb/s during one precipitous drop. While a cursory glance at averages could lead one to think this router can support HD streaming at distance, you have to watch where the graph bottoms out. This is the real qualifier. If, for example, a stream needs 10 or 20 Mb/s before system overhead, than this router clearly cannot deliver reliably under these conditions.
Lest anyone think we’re only picking on AirLive, let’s examine a TCP quartet from Asus. Looking at 11ac same-room performance, we get a little jiggle in the opening second or so as the connection stabilizes, then a long, stable plateau at 90+ Mb/s, then a sudden jump into the 140+ Mb/s range. Then when we switch to 802.11n, all semblance of stability vanishes. Performance swings across a 100% range from 70 to 140 Mb/s. This is obviously workable from an application standpoint, but it shows the striking variability of 11n throughput, even for such an excellent-performing router.
Going back to 11ac in our distance setting, we once more see a fleeting ramp-up in the connection, then an impressively narrow throughput band around 145 Mb/s. Seeing this performance level across the house still makes us giddy. Our 802.11n distance test shows another throughput leap in mid-test, but we again see a much broader performance band within the main plateau. Note, however, that we’re not seeing those drastic pits with Asus. Once it locks onto a throughput level, it’s very good about maintaining a floor.
Finally, let’s look at our remaining four routers under best-case TCP conditions. Even without looking at the y-axis numbers, Belkin is obviously out. Buffalo has the most stable, perfect-looking chart of the bunch, though Netgear gives Buffalo an interesting challenge. While it has that little warm-up blip, Netgear’s sustained throughput is slightly better than Buffalo’s. Linksys looks much more erratic, but watch those y-axis values. Numbers over 300 Mb/s for TCP? Dang!
Why we sometimes see those performance plateau shifts remains a mystery. Since we’re only seeing upward shifts in our data, in future testing we may want to look at patterns over longer periods of time, say a half-hour or more. Maybe these stable plateaus aren’t so stable with a longer time scale. These shifts happen in both test locations, so it’s not a local effect, nor does there seem to be a correlation with router/bridge combinations. It could have something to do with the TCP/IP stack, but digging into this will require additional research. For now, it remains a question mark to revisit another day.