On Thu, 12 Mar 2015, Dave Taht wrote:
so the wifi and ethernet queues are fq_codeled in this past SCALE.
One little understood fact about aggregated' wifi is that you CAN
actually FQ the faster rate ethernet queue with the theoretically
slower rate wifi queue, because a wifi aggregate is decoded at memory
speeds, not wire or wireless speeds, and thus, can fill the BQL
ethernet driver queue and have packets stuck at the qdisc layer, where
they can be handled more smartly.
That said, don't know if that ever happened at scale without data.
The wifi outgoing interfaces on each AP on the other hand, could very
well have had either the fq or the codel portions of the algorithm
engage... they certainly do on my tests here.
Although dlang did get quite a lot of data (which I have not yet seen,
or have I had time for - does anyone here have time to analyze it? He
got a ton of minstrel statistics in particular), but I am unsure if he
collected any of the tc -s qdisc data from the wifi interfaces. (?)
no, I missed/forgot the request for that.
it's about 20G of data uncompressed, I'm running lzma on it now to see how small
it will shrink.
I also have to note that the ath9k driver has got so good now, that a
ton of the benefit at scale probably came from that, and a great deal
more, from dlang's excellent design for the network itself. It is sad,
of course, that useful functionality like sta-to-sta transfers has to
be disabled in such environments nowadays.
I am really sorry I couldn't go.
I am seeing 25% better forwarding rates on ethernet out of 3.18 vs
3.10 on the same wndr 3800 hardware, btw.
hmm, does this have a noticable effect on the HTB throttling performance?
David Lang
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
