Re: [Make-wifi-fast] mesh deployment with ath9k driver changes

[Pete Heist <pete@heistp.net>]

> On Jul 5, 2018, at 3:08 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Pete Heist <pete@heistp.net> writes:
> 
>> And in the aqm driver support I’m not sure what fq_overmemory
>> signifies (Toke may know that) or if the other stats are within the
>> expected ranges for this amount of traffic.
> 
> Overmemory is the amount of times the total queue size went over the
> 4MiB limit. So I'd say that 60 million times is...quite a lot. Is there
> a lot of traffic that doesn't respond to congestion signals on that
> link?

Wow, ok. Well, I suspect it’s p2p. I watched some tcpdumps this morning of traffic with non-zero DSCP values and saw quite a lot of UDP packets with these higher DSCP values, which may be aggressive and not respond much to drops. It’s not always easy to classify that traffic to do something about it, but I could try. About 20% of overall traffic is UDP.

In response to seeing more traffic in the VO queues, this morning at around 10:30a I actually disabled the rate limiting (so I’m only testing one change at a time) and started zero-ing out DSCP values on all our access points, as well as our main router, with this: "iptables -t mangle -I PREROUTING -j DSCP --set-dscp 0”

I’m not holding my breath until I’ve seen a couple nights of data, but ping times have been lower since I made that change (https://www.drhleny.cz/smokeping/, and note that you may need to empty your cache if you’ve viewed this page before, so make sure you’re seeing the latest data).

This may not be a long-term solution, but it’s a test. I know doesn’t prevent people from sending packets to the AP with non-zero DSCP values, so they can still use the VO or other queues going to the APs (I can’t zero those values until the packets are out of the driver as far as I know), but at least traffic coming back from the Internet uses BE when it goes back to devices. I’ve seen in my point-to-point testing how lots of traffic in VO can destroy aggregate throughput.