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 wrote: > On Wed, Jun 24, 2015 at 4:31 AM, Mikael Abrahamsson > 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 >