<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 8:50 PM, Dave Täht <span dir="ltr"><<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
>     Android is still shipping linux 3.10? How... quaint.<br>
><br>> Since this is mobile, I'm pretty sure it will present a whole new host<br>
> of "data points".<br>
<br>
</span>yes! (there have been a few studies of this, btw)<br>
<br>
The part that we don't really know on the android handsets is how<br>
much buffering there really is between qdisc, driver, and firmware,<br>
which no doubt varies between models - and within a model on the<br>
different wifi and 4G stacks. Odds are - just as we just ripped out on<br>
the ath9k/ath10k - so much intermediate buffering exists as to make<br>
applying the latency managing qdisc on top of marginal effectiveness.<br>
<br>
In the case of BBR, well, there is some hope that would regulate<br>
TCP on the uplink, but it will have no effect on the down (neither will<br>
the qdiscs) - and it requires sch_fq to work properly - which<br>
means that you'd have a choice between bbr + sch_fq, or<br>
sch_cake/sch_fq_codel<br></blockquote><div><br></div><div>yet...  wouldn't BBR mitigate the local radio fw buffering?  The early rtt probing should (hopefully) see an un-bloated link, and then tune off of that?  So any local buffering would look like any other network path buffers.  True, it doesn't help with downlink data, but it may with the uplink.</div><div><br></div><div>I'm not sure that you can use cake on mobile, not with the sorts of wildly changing bandwidths that I've been seeing (<5 to >50Mbps within a few seconds, as one moves through varying lines-of-sight to the tower (say walking into a building, driving into a tunnel or just past a parking garage...).</div><div><br></div><div>-Aaron <br></div></div></div></div>