In testing *through* the linksys router later that day I was unable to get it to lock up.
I did also test inbound cake shaping at 900mbit inbound + outbound vs 900mbit outbound shaped, and 1gbit down unshaped, 900mbit shaped, on the flent tcp_upload_100 test (100 flows up, 1 down) http://snapon.cs.kau.se/~d/linksys-test/downshapedvsnotshaped.png as this build is running linux 3.18, it predates all the massive improvements in routing cache lookups that landed in 4.0-4.2. I strongly suspect that the heroic measures that the mvneta driver takes to create gro superpackets, which then go through act_mirred, which then cake heroically unpeels back into packets (mostly acks in the above test), and then each tiny packet which goes through the routing lookups before delivery to the next interface... are to blame for the massive difference in performance in the above graph. I'll retry the above with gro off on the inbound interface monday. In the meantime, perhaps (if there is a way to do it) merely peeling down to the cake quantum would help. And maybe there's a 4.x kernel or a backport of those wonderful routing lookup fixes.... Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Sat, Nov 28, 2015 at 10:19 PM, Imre Kaloz <ka...@openwrt.org> wrote: > Did you see https://lkml.org/lkml/2015/11/27/325 ? I'll try to find time to > integrate a newer kernel and that patchset as well as > https://lkml.org/lkml/2015/11/22/9 , > http://lkml.iu.edu/hypermail/linux/kernel/1511.0/04354.html and > http://lists.openwall.net/netdev/2015/09/25/151 > > > Imre > > > On Sat, 28 Nov 2015 15:41:17 +0100, Dave Taht <dave.t...@gmail.com> wrote: > >> I went for a test drive of openwrt DESIGNATED DRIVER (Bleeding Edge, >> r47665) today. >> >> A) I bricked the archer c7 v2. No idea why. >> >> B) I got a sorta working linksys 1200ac build. >> >> The bad news: Any attempt to run 2 or more copies of netperf's >> netserver on the 1200ac router with the default qdiscs (mq + >> fq_codel), at line (gbit) rate, result in it locking up *for any other >> traffic, including ping* until the first netperf is more or less >> complete. I fear the underlying driver is frightfully overbuffered, >> or has another problem. >> >> http://snapon.cs.kau.se/~d/archer-c7/onenetperflockout.png >> >> (needs BQL, too) >> >> The still bad news: cake works in both directions for a while longer, >> then goes boom similarly. >> >> The somewhat good news: >> >> cake "shaped" to 900mbit on inbound and outbound to the router - does >> not lock up the router. It merely runs out of cpu, but still does >> manage quite respectable throughput in both directions while doing >> so. Note, I did not say "latency". >> >> http://snapon.cs.kau.se/~d/archer-c7/encouraged.png >> >> As usual there is some flent data in that dir if you want to draw your >> own plots. >> >> I was not in a position to actually test traffic through the router >> (because I had the archer setup to do that) >> >> I wouldn't draw any conclusions from this. Well, a safe conclusion, >> is: don't install this build. >> >> On Sat, Nov 28, 2015 at 11:41 AM, Dave Taht <dave.t...@gmail.com> wrote: >>> >>> Trying to do my first openwrt build in a while. >>> >>> make[5]: Leaving directory >>> >>> '/home/cero4/src/archer-c7/build_dir/target-mips_34kc_musl-1.1.11/dante-1.2.2' >>> Makefile:349: recipe for target 'all' failed >>> >>> I checked: the package "dante" is not installed. Nor can I figure out >>> what package is arbitrarily requiring it. >>> >>> I truly am in hell. >> >> >> Simple patch for this, It involves invoking a deity. >> >> >>> Dave Täht >>> Let's go make home routers and wifi faster! With better software! >>> https://www.gofundme.com/savewifi _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel