From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound01.roaringpenguin.co.uk (outbound01.roaringpenguin.co.uk [109.69.238.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BDC183B29E for ; Sat, 11 Feb 2017 04:05:05 -0500 (EST) Received: from relay.smtp.pnsol.com (ec2-54-246-165-192.eu-west-1.compute.amazonaws.com [54.246.165.192]) by outbound01.roaringpenguin.co.uk (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v1B94uRX000973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Feb 2017 09:04:57 GMT Received: from mail.la.pnsol.com ([172.20.5.206]) by relay.smtp.pnsol.com with esmtp (Exim 4.82) (envelope-from ) id 1ccTcG-0000dS-Qw; Sat, 11 Feb 2017 09:05:12 +0000 Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1ccTa7-00013c-6c; Sat, 11 Feb 2017 09:02:59 +0000 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ccTY6-000Cdt-Ed; Sat, 11 Feb 2017 09:00:54 +0000 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9FD6668A-38E5-45DC-A749-B73616F7D971" From: Neil Davies X-Mailbutler-Link-Tracking-Uuid: In-Reply-To: Date: Sat, 11 Feb 2017 09:04:44 +0000 Message-Id: <99097E93-05AB-46F8-8545-E140C37ACAF3@pnsol.com> References: To: bloat X-Mailer: Apple Mail (2.3124) X-Spam-Score: undef - relay 54.246.165.192 marked with skip_spam_scan X-CanIt-Geo: ip=54.246.165.192; country=IE; region=Leinster; city=Dublin; latitude=53.3389; longitude=-6.2595; http://maps.google.com/maps?q=53.3389,-6.2595&z=6 X-CanItPRO-Stream: pnsol-com:outbound (inherits from pnsol-com:default, PredictableNetworkSolutions:default, Wholesale:default, CTL:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-CanIt-Archive-Cluster: Rl4fxI1RVOq/TTUYGiKHQwqlXy8 X-CanIt-Archived-As: pnsol-com/20170211 / 07SHl4U3d X-Scanned-By: CanIt (www . roaringpenguin . com) on 109.69.238.88 Subject: Re: [Bloat] I have a new record for bloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 09:05:06 -0000 --Apple-Mail=_9FD6668A-38E5-45DC-A749-B73616F7D971 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99ve 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. 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. The same mindset that created these sort of performance artefacts is = also driving changes in DSL=20 standards, so watch out for these sort of artefacts (again induced by = things that you have no direct control over) starting to occur in =E2=80=9Chigh speed=E2=80=9D DSL = systems (such as VDSL) when conditions are less than perfect. Neil > On 31 Jan 2017, at 20:42, Jim Gettys > wrote: >=20 >=20 >=20 > On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht > wrote: > On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood > 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=3D0 ttl=3D56 = time=3D42907.196 ms >=20 > 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. >=20 > =E2=80=8BI measured GoGo a couple years ago at about 740 seconds(!). >=20 > IIRC, we've seen some other cellular systems with bloat at >60 = seconds. >=20 > =E2=80=8BI 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 > =E2=80=8B >=20 > > 64 bytes from 8.8.8.8 : icmp_seq=3D1 ttl=3D56 = time=3D41922.290 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D2 ttl=3D56 = time=3D40971.714 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D3 ttl=3D56 = time=3D39967.402 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D4 ttl=3D56 = time=3D38964.115 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D5 ttl=3D56 = time=3D37986.640 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D6 ttl=3D56 = time=3D37026.309 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D7 ttl=3D56 = time=3D36073.683 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D8 ttl=3D56 = time=3D35075.141 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D17 ttl=3D56 = time=3D26273.867 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D18 ttl=3D56 = time=3D25268.726 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D19 ttl=3D56 = time=3D24270.618 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D20 ttl=3D56 = time=3D23269.550 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D21 ttl=3D56 = time=3D22265.406 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D22 ttl=3D56 = time=3D21264.648 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D23 ttl=3D56 = time=3D20305.022 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D24 ttl=3D56 = time=3D19316.740 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D26 ttl=3D56 = time=3D17310.953 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D25 ttl=3D56 = time=3D18316.163 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D27 ttl=3D56 = time=3D16320.196 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D28 ttl=3D56 = time=3D15409.592 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D29 ttl=3D56 = time=3D14411.919 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D30 ttl=3D56 = time=3D13505.362 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D31 ttl=3D56 = time=3D12505.893 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D32 ttl=3D56 = time=3D11502.744 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D33 ttl=3D56 = time=3D10501.390 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D34 ttl=3D56 = time=3D9560.551 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D35 ttl=3D56 = time=3D8566.430 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D36 ttl=3D56 = time=3D7570.286 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D37 ttl=3D56 = time=3D6588.928 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D38 ttl=3D56 = time=3D5643.342 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D39 ttl=3D56 = time=3D4639.435 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D40 ttl=3D56 = time=3D3722.169 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D41 ttl=3D56 = time=3D2719.881 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D42 ttl=3D56 = time=3D1806.913 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D43 ttl=3D56 = time=3D1218.198 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D55 ttl=3D43 = time=3D1030.052 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D56 ttl=3D43 = time=3D638.601 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D57 ttl=3D43 = time=3D216.295 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D58 ttl=3D43 = time=3D200.674 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D59 ttl=3D43 = time=3D797.261 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D60 ttl=3D43 = time=3D992.238 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D61 ttl=3D43 = time=3D1696.089 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D62 ttl=3D43 = time=3D1139.896 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D63 ttl=3D43 = time=3D588.823 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D64 ttl=3D43 = time=3D663.070 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D65 ttl=3D43 = time=3D782.507 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D66 ttl=3D43 = time=3D426.705 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D67 ttl=3D43 = time=3D220.192 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D68 ttl=3D43 = time=3D228.405 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D69 ttl=3D43 = time=3D130.555 ms > > 64 bytes from 8.8.8.8 : icmp_seq=3D70 ttl=3D43 = time=3D210.779 ms > > > > -Aaron > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat = > > >=20 >=20 >=20 > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat = >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat = --Apple-Mail=_9FD6668A-38E5-45DC-A749-B73616F7D971 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99ve 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.

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.

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 =E2=80=9Chigh speed=E2=80=9D= DSL systems (such as VDSL) when conditions are less
than perfect.

Neil

On 31 Jan 2017, at 20:42, Jim = Gettys <jg@freedesktop.org> wrote:


On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
On = Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77@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=3D0 ttl=3D56 time=3D42907.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.

=E2=80=8BI measured GoGo a couple years ago at about 740 = seconds(!).

IIRC, we've seen some other = cellular systems with bloat at >60 seconds.

=E2=80=8BI 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
=E2=80=8B

> 64 bytes from 8.8.8.8: icmp_seq=3D1 = ttl=3D56 time=3D41922.290 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D2 = ttl=3D56 time=3D40971.714 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D3 = ttl=3D56 time=3D39967.402 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D4 = ttl=3D56 time=3D38964.115 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D5 = ttl=3D56 time=3D37986.640 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D6 = ttl=3D56 time=3D37026.309 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D7 = ttl=3D56 time=3D36073.683 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D8 = ttl=3D56 time=3D35075.141 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D17= ttl=3D56 time=3D26273.867 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D18= ttl=3D56 time=3D25268.726 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D19= ttl=3D56 time=3D24270.618 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D20= ttl=3D56 time=3D23269.550 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D21= ttl=3D56 time=3D22265.406 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D22= ttl=3D56 time=3D21264.648 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D23= ttl=3D56 time=3D20305.022 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D24= ttl=3D56 time=3D19316.740 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D26= ttl=3D56 time=3D17310.953 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D25= ttl=3D56 time=3D18316.163 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D27= ttl=3D56 time=3D16320.196 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D28= ttl=3D56 time=3D15409.592 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D29= ttl=3D56 time=3D14411.919 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D30= ttl=3D56 time=3D13505.362 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D31= ttl=3D56 time=3D12505.893 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D32= ttl=3D56 time=3D11502.744 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D33= ttl=3D56 time=3D10501.390 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D34= ttl=3D56 time=3D9560.551 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D35= ttl=3D56 time=3D8566.430 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D36= ttl=3D56 time=3D7570.286 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D37= ttl=3D56 time=3D6588.928 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D38= ttl=3D56 time=3D5643.342 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D39= ttl=3D56 time=3D4639.435 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D40= ttl=3D56 time=3D3722.169 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D41= ttl=3D56 time=3D2719.881 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D42= ttl=3D56 time=3D1806.913 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D43= ttl=3D56 time=3D1218.198 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D55= ttl=3D43 time=3D1030.052 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D56= ttl=3D43 time=3D638.601 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D57= ttl=3D43 time=3D216.295 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D58= ttl=3D43 time=3D200.674 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D59= ttl=3D43 time=3D797.261 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D60= ttl=3D43 time=3D992.238 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D61= ttl=3D43 time=3D1696.089 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D62= ttl=3D43 time=3D1139.896 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D63= ttl=3D43 time=3D588.823 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D64= ttl=3D43 time=3D663.070 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D65= ttl=3D43 time=3D782.507 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D66= ttl=3D43 time=3D426.705 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D67= ttl=3D43 time=3D220.192 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D68= ttl=3D43 time=3D228.405 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D69= ttl=3D43 time=3D130.555 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D70= ttl=3D43 time=3D210.779 ms
>
> = -Aaron
>
> = _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better = software!
http://blog.cerowrt.org
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

_______________________________________________
Bloat mailing = list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

= --Apple-Mail=_9FD6668A-38E5-45DC-A749-B73616F7D971--