[Bloat] some notes on the archer c7v2's suitability for make-wifi-fast

[Dave Taht]

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