> On Feb 9, 2017, at 3:44 PM, Toke Høiland-Jørgensen wrote: > > Pete Heist writes: > >> I’ll mention one example I noticed of the kind of adjustment that >> probably can’t be done from the qdisc layer today. On page 3 from >> http://pollere.net/Pdfdocs/noteburstymacs.pdf: >> >> "In addition to increasing the interval by the waiting delay s, >> another adjustment might be useful for certain kinds of bursty MACs. >> If the MAC is a request-and-grant type, as wifi in infrastructure >> mode, cable modems and some satellite modems, the allocation of bytes >> or packets that can be sent during each transmission slot is generally >> known at the beginning of transmission and may vary for each >> transmission slot. In that case, it MAY be useful to use that value >> instead of the MTU value to reset first_above_time_." > > Yeah, we've had this issue with CoDel when the per-station WiFi rate > drops too low (this is a function of both signal quality and number of > stations). As a temporary fix, I just fiddled with the target until > CoDel stopped being too aggressive, but that is not a proper solution, > and so has not been upstreamed. I'm planning to get back around to > fixing that properly at some point... Problem is that it is not always > the case that "the allocation of bytes or packets that can be sent > during each transmission slot is generally known". For ath9k we could > get at this information at dequeue time, but for ath10k, only the > firmware knows ahead of time... > > -Toke Interesting, I hope there’s a solution. Here are the fixed MCS level results I saw yesterday: http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png in case anything can be seen in it related to this. I noticed that for the ath9k driver CoDel latency maxed out at 45 ms at around MCS 10, and didn’t get any higher down to MCS 8. Overall, the CoDel / Cake algorithms seem to keep rrul latency much lower than sfq at lower bitrates, but the differences are smaller at higher bitrates. More results later... Pete