From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 482F53B2A4 for ; Sat, 11 Feb 2017 13:24:17 -0500 (EST) Received: by mail-qk0-x244.google.com with SMTP id p22so1289975qka.3 for ; Sat, 11 Feb 2017 10:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KwL1iKCSpgvRmtqdwYGwq6gNUQ8VT1pEN396XxpORsg=; b=S5Emx4VlZiAW3L0oNVNwBUfLfre+oW6f4TGywOb4yDNYalyPArLh1zzLNapRsLSRna lT67f+pA20Qn9pPVrboczEKSsit41Ycy+vElBq53Ojy02EOrKBqPPOm94JtT4esxV57L VdjcrwF0U9Z0DjBBLa8ZyMC76m5RMnRu6MdnbC7msr/z2TZNACL6YIdW8DJcrp+T2O5i b6v9Ne1U8y3XsYTZIWQrSkr+sFxTVgKsPyBR1KHm+ClwdnrKrTENCfe4/mF9fK4HSBon 1mhNGo39kdo6TRUPvzevd6OoqqEL/TlEyun1YqmHA4KkZvDA+OAfKIjLKcdFgBR7tO8f tiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KwL1iKCSpgvRmtqdwYGwq6gNUQ8VT1pEN396XxpORsg=; b=QQGH1FIZdOBHRZEWvFoFkzuEr2TcDbGIySxJjmmCS+wCQAXOTQ1RaLn+jWiUMZXWLT flVwjt86OCJ3yICxmOzPB0/tc3/VBF/5wzWbxgnhrC77g8SnlLYhr2/uO1SGyy1NL386 GWF37LpxXgaOYqRSz3z4kTQNeA8QGX4WCh82FV1+yeh3ms9SiKL5Mx5CnCR+vlFeL6x6 eMDyBsr5TZVxg6s41zUGHnLzdj92+Ls0f1yX77l28b+qq0Y/0MAS+nQQr7b3lG1LzRnG LTPX5RiDNu+4pok5tPmmYfycf1zsbjiqfAZHV1jfHaGSGdDmmGMSx9JaHtCgqnzRQe2X xNZw== X-Gm-Message-State: AMke39kw/jlRPp1PbSJojjNKYmt/gLOUrkovDLyiS7stuEOrE8GvSjNliyqxUdr41dIaqkVu2DLgFPGVkrWZuw== X-Received: by 10.55.20.200 with SMTP id 69mr1402444qku.59.1486837456755; Sat, 11 Feb 2017 10:24:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.132 with HTTP; Sat, 11 Feb 2017 10:24:16 -0800 (PST) In-Reply-To: <99097E93-05AB-46F8-8545-E140C37ACAF3@pnsol.com> References: <99097E93-05AB-46F8-8545-E140C37ACAF3@pnsol.com> From: Dave Taht Date: Sat, 11 Feb 2017 10:24:16 -0800 Message-ID: To: Neil Davies Cc: bloat , Jim Gettys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 18:24:17 -0000 On Sat, Feb 11, 2017 at 1:04 AM, Neil Davies wrote: > We=E2=80=99ve measured timings like this on many 3GPP based systems in va= rious > 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 duri= ng > 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 thi= ngs > that you have no direct > control over) starting to occur in =E2=80=9Chigh speed=E2=80=9D DSL syste= ms (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 wrote: > > > > 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 th= e >> > 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. > > > 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-Mobi= le > (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=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 > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org