<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 3:44 PM, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk" class="">toke@toke.dk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Pete Heist <<a href="mailto:peteheist@gmail.com" class="">peteheist@gmail.com</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">I’ll mention one example I noticed of the kind of adjustment that<br class="">probably can’t be done from the qdisc layer today. On page 3 from<br class=""><a href="http://pollere.net/Pdfdocs/noteburstymacs.pdf:" class="">http://pollere.net/Pdfdocs/noteburstymacs.pdf:</a><br class=""><br class="">"In addition to increasing the interval by the waiting delay s,<br class="">another adjustment might be useful for certain kinds of bursty MACs.<br class="">If the MAC is a request-and-grant type, as wifi in infrastructure<br class="">mode, cable modems and some satellite modems, the allocation of bytes<br class="">or packets that can be sent during each transmission slot is generally<br class="">known at the beginning of transmission and may vary for each<br class="">transmission slot. In that case, it MAY be useful to use that value<br class="">instead of the MTU value to reset first_above_time_."<br class=""></blockquote><br class="">Yeah, we've had this issue with CoDel when the per-station WiFi rate<br class="">drops too low (this is a function of both signal quality and number of<br class="">stations). As a temporary fix, I just fiddled with the target until<br class="">CoDel stopped being too aggressive, but that is not a proper solution,<br class="">and so has not been upstreamed. I'm planning to get back around to<br class="">fixing that properly at some point... Problem is that it is not always<br class="">the case that "the allocation of bytes or packets that can be sent<br class="">during each transmission slot is generally known". For ath9k we could<br class="">get at this information at dequeue time, but for ath10k, only the<br class="">firmware knows ahead of time...<br class=""><br class="">-Toke<br class=""></div></div></blockquote></div><br class=""><div class="">Interesting, I hope there’s a solution. Here are the fixed MCS level results I saw yesterday:</div><div class=""><br class=""></div><div class=""><div class=""><a href="http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png" class="">http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png</a></div><div class=""><br class=""></div><div class=""><a href="http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png" class="">http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png</a></div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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...</div><div class=""><br class=""></div><div class="">Pete</div><div class=""><br class=""></div></body></html>