From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 05AB13B29E for ; Wed, 24 Jun 2020 04:56:51 -0400 (EDT) Date: Wed, 24 Jun 2020 08:56:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1592989010; bh=0zCoKD2yuvupG1glDY+GDuTfUyv4qih5WDOES+svAO8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=yj4KLNmQpVkvxfcxOvrUj0pxunRqK26VhLvit8Fmtc7GEcBUHyFzkqehr6/3SPiJK 8jK1D8sOwLLlPd1msqE9yS4MxkYbtVDC02gibgAVRQNtLzm7gFZe84ewXNseflhzua br0Aq716PXDYUjAJHDvyASM/0g5xyUfMmjUxmfp8= To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= From: Michael Yartys Cc: Simon Barber , "make-wifi-fast\\@lists.bufferbloat.net" Reply-To: Michael Yartys Subject: Re: [Make-wifi-fast] Bufferbloat on Norwegian train wifi Message-ID: In-Reply-To: <87o8part1d.fsf@toke.dk> References: <87tuz3tgaq.fsf@toke.dk> <87o8part1d.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-List-Received-Date: Wed, 24 Jun 2020 08:56:52 -0000 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, 23 June 2020 12:11, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Michael Yartys michael.yartys@protonmail.com writes: > > > Wow, those are some truly crappy networks! > > Yeah, 'bloat-bragging' seems to have become quite the sport on these > mailing lists ;) > > > I'll try to contact Vy to get them to do something about it. I wonder > > how much of this might be due to the equipment on their trains though. > > I decided to measure the bufferbloat on the LTE network in my > > neighbourhood, and on average I got 300 ms above baseline while > > running an 8-stream TCP download. Then again, I ran this test with my > > phone acting as a hotspot, and the results might be affected by that. > > Does anybody know if this methodology produces reliable results? I > > presume that even the very short peak of 86 Mbps shouldn't really > > cause much WiFi-related bufferbloat. > > Hard to say from first principles. 300ms doesn't sound unrealistic for > bloat on an LTE network and if you have a good WiFi connection on your > phone the WiFI link shouldn't be a bottleneck. But it's hard to know > for sure; just too many variables. > > I guess you could try running a speedtest on your phone while you have a > ping running from your tethered laptop. Not sure how effective the > app-based speedtests are at inducing bloat, though; they're certanly not > measuring it... Thanks for the suggestion! It seems like I get results that are in line wit= h what I got when running the flent test. I'll contact my mobile service pr= ovider as well to check if they're aware of the bufferbloat issue. Also, if anyone's interested, I found an interesting paper about bufferbloa= t experienced during uploading on 4G networks: https://www-users.cs.umn.edu= /~fengqian/paper/bufferbloat_imc16.pdf > > -Toke