From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B463C21F4F2 for ; Tue, 28 Jul 2015 09:22:33 -0700 (PDT) Received: from u-089-d060.biologie.uni-tuebingen.de ([134.2.89.60]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lmwpk-1YhUa01nem-00h7G3; Tue, 28 Jul 2015 18:22:28 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <14ed5136170.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> Date: Tue, 28 Jul 2015 18:22:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87a8ugqvid.wl-jch@pps.univ-paris-diderot.fr> <87r3nstnj5.fsf@toke.dk> <876154qtkt.wl-jch@pps.univ-paris-diderot.fr> <87mvygtm1a.fsf@toke.dk> <14ed5013130.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1438093312.20182.49.camel@edumazet-glaptop2.roam.corp.google.com> <14ed5136170.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> To: Simon Barber X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:Thniwl+xZUTl5zPa5PXed0Nm0RlWeBJErGhyAcRaINtSzFqkwKe BuoQTbC76HJLLxXXM64d1rlqxPgLMTuj7IW9qhQ9gmy71fkANtt60gbJ5nMmW7bgXT0iPPO bgIE5Tq0d+LR0T7LQXmr18/PJ5mfbudaPmDt5/ks22/jhlbdVJ9qBsE5xAFUixNHbeqF9Tx 2pk4GmHacWuYWLxcP3nVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:k26mQyd4FE4=:aLEEG239WBr2ZwX4fBZ8O/ cCpP26e8fa1ladqmxsW1AJSvBSSLKWFZ7GZmBUsZ2stTISPUYKwa4tziP749RcoKX6omt5RmD tGqNdH/G87HRqdvgrXgKFWVStnpLdJE26Z6xTLwHxApLbsdy6/ANSgxYJwK9sbHziPeKw/8tF AKR2f3323StHuu0qxb2uXIMeHc6AvrmgkLhzNVN6kmb9NSDen20bIc3KvKmjzpfCkaOfZ81VJ MCVzz9oEDnBeYGovTiNpkRW8X9NI4WHyCdP690PqigK3EEbOzVL8zP1tygYisWZ73hFv7Y1B5 MKeUS3jmMno7Pgk5dbDDKlFzmQfpjSkMZ0NXI5P97znSVd8V/V/lmRbazraRAM0JrpOWzkKNK DkopSnP3RNCzQ6+0cKC2Zk+H3ZJYxkmj2317+DDt9kv7OmNzTh1NWrEWrS+aP8lJd4Nc6+3g/ hSk/baZ4acpIX5XPCBBJHhv+YoVQb0e1SMjR4YKsDvRCDLMWjbbLA5Lg17v/ng8piPRDpDxJk ADUzgzaUWpIZ6ECF7ig+AAM4b+ciXQmCNx5RWKsZBRP+3IZ/DZfSbAtWaAbjR3U9kiyhr1QVN rb0/IvEbKu4uc5S3/4bbZqykUjKknQuPLcKYh5PSrCuR+WnnfOFCEdeenBmNqKNppvDNpjghT x2agqXZSVKxqCQ2MFE5NNyPurWf3RNr82XehaTBhRltZMimOGd77TfXQp1FBKDK3GUXM= Cc: Juliusz Chroboczek , bloat Subject: Re: [Bloat] AQM and PPP on Linux X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 16:23:02 -0000 Hi Simon, On Jul 28, 2015, at 16:31 , Simon Barber wrote: > The issue is that Codel tries to keep the delay low, and will start = dropping when sojourn time grows above 5ms for 100ms. For longer RTT = links more delay is necessary to avoid underutilizing the link. This is = due to the multiplicative decrease - it's worst with Reno, where the = halving of cWind means that you need to have a full BDP of data in the = buffer to avoid the link going idle when cWind is halved. With longer = RTTs this means more delay than Codel allows is required to avoid a = throughput hit. The worst case happens when a single flow is controlled, = but that can be a common situation. My proposal is to sense and have the = target value in Codel automatically adjust when this worst case scenario = happens - which would mitigate most of the downside. According to theory you should adapt interval if at all and the = set target between 5-10% of that interval. See = https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=3D1 = sections 4.3 and 4.4. Now that could all be off.The upshot is increasing = target as a response for long RTTs will sacrifice latency again for = bandwidth, pretty much that the avoidance of is codel=92s claim to fame = ;) Best Regards Sebastian >=20 > Simon >=20 > Sent with AquaMail for Android > http://www.aqua-mail.com >=20 >=20 > On July 28, 2015 7:21:56 AM Eric Dumazet = wrote: >=20 >> On Tue, 2015-07-28 at 07:11 -0700, Simon Barber wrote: >> > The main danger is the negative effects on performance of using = Codel. You >> > may experience low throughput on high RTT links. >>=20 >> Really ? I've never seen this, unless you mess with codel qdisc >> attributes maybe. >>=20 >> (Some guys seem to not really understand whole concept of a queue, = and >> set very low values for 'limit' attribute for example) >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat