I took the archer c7v2 out for a set of test runs over the weekend. A) The good news: I couldn't crash it with a full workload nor overheat it with external temps at at 23C. I had tested the 3800 with external temp of 44C, and i would prefer to test any new product at that before wanting to use it here.
It was easy to configure from my test build on snapon, only needing the addition of the kmod-ath10k package to have support for both radios. the gui seems to work well in that test build the "new" cake2 shaper/fq/codel qdisc (barely) managed to deal with 115mbit down and 12mbit up with 5% or so of cpu to spare with bridging and hostapd turned off. (htb + fq_codel fell apart at 90mbits.) I think cake can be improved quite a bit more and we really need to do some profiling to find other bottlenecks. having both an ath9k (fixable) and an ath10k (ac, probably not fixable) in the box is something of a plus also. B) The bad news: I didn't get around to testing wifi at all. I ran into an interesting problem, where testing it with full nat enabled, with no sqm-scripts, would peak at about 400 mbits on the rrul test, and: 0) If hostapd was running it would run a lot - cutting performance by about 50Mbits on the test runs. I think I posted the strace here already. 1) the queues for both eth1 and eth0 (wan and lan, respectively) would fill up - quite a lot, 100s of packets, on the rrul tests. Even though the base rate of the ethernet interfaces was a gigabit, the box could not service interrupts fast enough to clear out the device queues in either direction, thus engaging fq_codel as part of the overall cpu overload-handling mechanism to reduce the queue sizes somewhat. So I saw fairly long delays (7ms or more) when running at these speeds through the router. While reducing queue size when running out of cpu is a pleasing result, it also points to possible tuning options for napi, maybe adding xmit_more support in (or removing it entirely), in order to fully service all interrupts in one direction or another, and also compile options specific to the mips74k which has a long pipeline in particular, and so far as I know the archer has no issues (as the wndr3800 had) with unaligned access so we can turn off various hacks on that front. A linux feature I have long longed for is to do all timestamping (as well as calculating the 5 tuple) on the rx path, and the tx path leveraging that hash to fq on, and merely checking the rx entry time on dequeue for codel. (I know how hard this is to do, but it has become easier in more recent linux kernel versions. This would better account for running out of cpu in the router, and IMHO work better on cache-hot data on the rx side) I have 4 more routers in my stack, so far the two dlink ones were horrible, next up are the buffalo and belkin boxes, which I hope to get to next weekend. With a bit more testing of the wifi, the tplink archer c7v2 may prove out to be "not horrible" and a suitable candidate for make-wifi-fast, but I think the cpu limitation is kind of bad and would really like to try a quad mips or dual arm core. And normally I don't leave nat running, and left my dataset behind on the test box behind this router when I left for SF yesterday. :( -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
