[Make-wifi-fast] 30+ sec of miserable bufferbloat in wearOS

Dave Taht dave.taht at gmail.com
Sun Apr 7 23:44:05 EDT 2019


On Sun, Apr 7, 2019 at 9:11 PM Xiao Zhu <shawnzhu at umich.edu> wrote:
>
> Dear Dave Taht,
>
> Thank you for pointing out those two great papers and paying attention to our recent work.

It is my hope that the insights (and running code) in the those papers
are one day applied widely to 4g, 5g, GPON, MOCA, and homeplug
devices.

Homeplug, in particular, is oft horrific (
http://caia.swin.edu.au/reports/130121A/CAIA-TR-130121A.pdf ), and
early 5g results, also.

> In the context of wearable networking where the bottleneck is the Bluetooth link between the smartphone and the smartwatch, the solutions you mentioned can conceptually help to handle bottleneck queuing at lower layers, but it could be hard to execute them given the Bluetooth stack in Android is very different from that of WiFi/LTE and does not speak TCP/IP.

Bluetooth was not on my radar until reading your paper! I have in
general noticed a unusable amount of buffering for interactive
applications on both bluetooth and hdmi.

>
> In our future bufferbloat-related work, we will definitely discuss more related works, especially those you mentioned.
>
>
> Best,
> Xiao
>
> On Sat, Apr 6, 2019 at 8:14 PM Dave Taht <dave.taht at gmail.com> wrote:
>>
>> "When acting as a gateway proxy for a wearable, the phone dramatically
>> inflates the end-to-end (server to wearable) latency to 30+ seconds
>> due to its incurred “bufferbloat”. We then break down the end-to-end
>> latency into various components, and identify the root cause to be the
>> phone-side TCP receive buffer, whose configuration does not take into
>> account the path asymmetry between the wearable-phone path and the
>> phone-server path... " -
>> https://anikravesh.github.io/files/wearos-sigmetrics19.pdf
>>
>> I am of course puzzled as to why they didn't look into sch_cake[1] or
>> fq_codel derived solutions[2], (it is a non-open source OS) but they
>> did manage to eliminate 97% of the problem in their paper, so, there's
>> that.
>>
>> [1] https://arxiv.org/abs/1804.07617
>> [2] https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf
>> --
>>
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-205-9740
>
>
>
> --
> Xiao (Shawn) Zhu
> PhD Candidate, Computer Science & Engineering
> University of Michigan, Ann Arbor, MI 48105
> Email: shawnzhu at umich.edu
> Phone: 734-263-0338



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740


More information about the Make-wifi-fast mailing list