I've noticed this off/on with first the WNDR3800, and now the WRT1900AC. The rates I enter for the sqm_scripts aren't being met, and not, I think, because of CPU load issues, but something about the book-keeping.
Here's a set of tcp_download tests on the WNDR3800, the ingress rate limits are in the legend:
The WNDR holds up linearly until 90Mbps, and then it's clear that everything's come apart. With the measured "good-put" at an eyeballed 95% of the rate that's setup in the limiter. This is likely to be expected TCP overhead vs. the raw line bit-rate (which is where the limiter is running).
However, on the WRT1900AC, it's off rather significantly:
Maybe 80% of the target ingress rate?
+Dave Taht suggested I turn off TCP offloads, and it got less linear, worse on the low-end, better on the higher end.
This is definitely going to take some more testing (and longer test runs) to map out what the issue(s) might be.
**
Corrections: This post previously stated that the WNDR3800 was falling short, but after talking with some other people, I think that's likely just the expected overhead of TCP, which becomes a more-obvious difference between the raw line rate and the "good-put" as bandwidths go up (5Mbps is easier to see than 500Kbps).
No comments:
Post a Comment