Hi Aaron,

about the 5% loss with the wndr, please remember that the shaper works typically on raw Ethernet rates, while flent reports TCP good put I believe. So roughly 2 to 6 percent difference can be explained with a combination of the following overheads: PTM/ATM, ethernet, VLAN(s), PPPoE, IPv4/IPv6, TCP, potential TCP options like timestamps... Now flent might report actual tcp-rates and I am out to lunch, but I have a hard time reconciling how flent/netperf, can actually learn about all the additional overhead... As far as I can tell all netperf sees is the payload it sends and the payload it receives...
Tl;dr: Overhead unknown to flent effortlessly explains why the TCP good put as reported by flent falls short of the shaped rate as that rate contains all overheads.


Best Regards
Sebastian

On June 3, 2015 7:45:47 AM GMT+02:00, Aaron Wood <woody77@gmail.com> wrote:
I wrote this up on my blog, where I can intersperse text and graphs a bit better:

http://burntchrome.blogspot.com/2015/06/htb-rate-limiting-not-quite-lining-up.html

Basically, I ran a series of tcp_download tests, using increasing ingress rates with sqm_scripts, and then used flent's box-plots to put the results into a combined image for comparing.

On the 3800, it never meets the rate, but it's only off by maybe 5%.  But on my new WRT1900AC, it's wildly off, even over the same performance range (I tested it from 80-220Mbps rates in 20Mbps jumps, and saw from 40-150Mbps.

I have no idea where to start looking for the cause.  But for now, I'm just setting my ingress rate MUCH higher than I should, because it's working out to the right value as a result.

-Aaron


Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.