[Bloat] I have a new record for bloat

Dave Taht dave.taht at gmail.com
Sat Feb 11 13:24:16 EST 2017 

On Sat, Feb 11, 2017 at 1:04 AM, Neil Davies <neil.davies at pnsol.com> wrote:
> We’ve measured timings like this on many 3GPP based systems in various
> countries.
>
> It is an interaction between the radio link protocol, other parts of the
> 3GPP data path and way
> in which such devices are integrated with the operating system (even in
> iOS), it is
> not about the quantity of buffers but more the protocol interactions during
> times of stress on the
> radio bearer and/or during handover.

Meh. On a handover - with less buffering - packet lossage would barely
bother anyone.

> There are protocol configuration options, different design objectives and
> operational management
> mechanisms they _could_ use, but there is no incentive for the cellular
> operators to invest the
> time and effort to investigate and resolve.

At one level this lets ISPs continue to be necessary for good network
performance, and a way for them to differniate themselves from the
cellular folk. (if they were listening, also)

At least a few within the celluar industry are listening - apparently
NEC wasn't, but Dirk, here, just moved onto Huawei....

http://dirk-kutscher.info/posts/5g-its-the-network-stupid/


> The same mindset that created these sort of performance artefacts is also
> driving changes in DSL
> standards, so watch out for these sort of artefacts (again induced by things
> that you have no direct
> control over) starting to occur in “high speed” DSL systems (such as VDSL)
> when conditions are less
> than perfect.

I am extremely grumpy that despite the general availability of the
BQL[1] technique (less than 50 lines of code!) for managing
ring-buffers simply in firmware designed to operate at a range of
configured speeds... *especially* including both old style and modern
DSL chipsets...

only free.fr has actually implemented something like it. 3 months
after we shipped fq_codel. in 2012.

[1] https://lwn.net/Articles/454390/

It's in all the major ethernet drivers now, at least.

> Neil
>
> On 31 Jan 2017, at 20:42, Jim Gettys <jg at freedesktop.org> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht <dave.taht at gmail.com> wrote:
>>
>> On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77 at gmail.com> wrote:
>> > This is wifi tethering from my OSX laptop to my iPhone, right after the
>> > laptop tried to reconnect to the iphone after waking up.
>> >
>> > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=42907.196 ms
>>
>> Not even close for the record as we got something like 800 seconds out
>> of gogo-in-flight. But as for wifi + tethering, you "win", I guess.
>
>
> I measured GoGo a couple years ago at about 740 seconds(!).
>
> IIRC, we've seen some other cellular systems with bloat at >60 seconds.
>
> I don't understand what I'm seeing at the moment on my Pixel XL on T-Mobile
> (upstream).  I need to retake the data and post it along with the qdisc
> structure on current Android, for people to mull over.
>                                     - Jim
>>
>>
>> > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=41922.290 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=40971.714 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=39967.402 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38964.115 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=37986.640 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=37026.309 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=36073.683 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=35075.141 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=17 ttl=56 time=26273.867 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=18 ttl=56 time=25268.726 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=19 ttl=56 time=24270.618 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=20 ttl=56 time=23269.550 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=21 ttl=56 time=22265.406 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=22 ttl=56 time=21264.648 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=23 ttl=56 time=20305.022 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=24 ttl=56 time=19316.740 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=26 ttl=56 time=17310.953 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=25 ttl=56 time=18316.163 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=27 ttl=56 time=16320.196 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=28 ttl=56 time=15409.592 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=29 ttl=56 time=14411.919 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=30 ttl=56 time=13505.362 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=31 ttl=56 time=12505.893 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=32 ttl=56 time=11502.744 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=33 ttl=56 time=10501.390 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=34 ttl=56 time=9560.551 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=35 ttl=56 time=8566.430 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=36 ttl=56 time=7570.286 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=37 ttl=56 time=6588.928 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=38 ttl=56 time=5643.342 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=39 ttl=56 time=4639.435 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=40 ttl=56 time=3722.169 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=41 ttl=56 time=2719.881 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=42 ttl=56 time=1806.913 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=43 ttl=56 time=1218.198 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=55 ttl=43 time=1030.052 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=56 ttl=43 time=638.601 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=57 ttl=43 time=216.295 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=58 ttl=43 time=200.674 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=59 ttl=43 time=797.261 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=60 ttl=43 time=992.238 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=61 ttl=43 time=1696.089 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=62 ttl=43 time=1139.896 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=63 ttl=43 time=588.823 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=64 ttl=43 time=663.070 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=65 ttl=43 time=782.507 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=66 ttl=43 time=426.705 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=67 ttl=43 time=220.192 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=68 ttl=43 time=228.405 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=69 ttl=43 time=130.555 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=70 ttl=43 time=210.779 ms
>> >
>> > -Aaron
>> >
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>> >
>>
>>
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

More information about the Bloat mailing list