Here's a long-range (indoors) test result with the 1900AC.  I have about 9dB snr at the client (all the way across my house, which has plaster walls):

http://www.dslreports.com/speedtest/737736

download buffering is the 1900ac, upload buffering is the mac laptop's driver.  Both are trying too hard to deliver those packets, I think.

The driver has crazy over-buffering in the face of poor signal conditions.  OTOH, I'm amazed at the throughput numbers.  But this is an 80Mhz wide 5Ghz channel, in a quiet environment, so it has LOTS of airspace to work in.

-Aaron

On Wed, Jun 24, 2015 at 9:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
On Wed, Jun 24, 2015 at 4:31 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 23 Jun 2015, Sebastian Moeller wrote:
>
>> As Dave said it would be nice see RRUL data from the same testbed. It
>> would be so nice if flint had a way to send different sized TCP packets… (I
>> guess this might be faked with MSS clamping in the router and relaying on
>> path MTU discovery?)
>
>
> What kind of tests should I run? I have rrul results now, both at the same
> time as running iperf3. I set iperf3 to run with 10 parallel streams,
> different MSS per test, and let it run for 30 seconds into the rrul test. So
> in all the tests, iperf3 session stops running half way into the rrul test.
>
> I set sqm to 500M up and down on eth0, ECN up and down, and not to squash
> DSCP in any direction.
>
> http://swm.pp.se/aqm/rrul-wrt1200ac-150624.pdf

From what I see here you are rarely, if ever, engaging fq_codel
properly. Latencies are pretty high. In particular, I would suspect
you are hitting offloads hard, and the current (fixed in linux 4.1)
codel drop algorithm stops dropping below "maxpacket", which was meant
in the ns2 code to be a MTU, but in the linux code ended up being a
TSO sized (64k!) packet.

tc -s qdisc show # will show the maxpacket.

> Tell me if there is more information I can provide or tests to run.

0) I tend to have a script for everything... I can give you an example
script in another email.

1) tc -s qdisc show dev whatever # will show actuall drop/mark statistics

2) Please run your flent tests with -x --disable-log

-x collects more metadata, --disable-log disables the automatic log
scaling which is so hard to discern on these plots.

Use -t "title" to differentiate between variables under test.

3) I also tend to use flent's --remote-metadata=root@your_openwrtbox
to get the stats on that box into the metadata. You have to add your
local .ssh/id_rsa.pub key to
your_openwrtbox:/etc/dropbear/authorized_keys file to do this.

4) With all that in hand, sticking up a tarball of the results makes
for easy plotting of various other graphs, and using the flent-gui,
you can combine results from each run easily, also.

5) try disabling offloads on all interfaces on the router (or running cake)

My usual suite of tests is rrul, rrul_be, tcp_1up, tcp_1down, and tcp_2up_delay.

and rtt_fair (if you have more than one target server available)...
all without the iperf stuff....

Your mss changing idea is interesting, and I would like to do a mod to
tcp_2up_delay to sort of match your iperf combination + flent to
totally capture all data.

6) I am pretty interested as to what happens *without* sqm at the max
forwarding rate with fq_codel engaged on all these tests.

>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



--
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel