From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 80D4621F8A2 for ; Tue, 28 Jul 2015 09:02:45 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so163995069wib.0 for ; Tue, 28 Jul 2015 09:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=drvmVr5P0Jcp+z6uyrZPridNqYSK0zQkodGysg1R8QM=; b=VOvXg+K/pxNELQnIsHr1l9D+6G1FcOmSAOSSs70ekuujsjCsfNePSDLMuMsW5QRFGd xsIDikaRX0bwisNraPggBo6Jd77JUi22VYqKYOm6sZ992AlTzlUAGvORAMocwYg3qe+u IPuz0HBAFwwx6NXFCA5411uljGpb9M4rnU2zVwjYujgsNeE5BoMNtsjk7rsl19FC9sGO 8mC6nEfhDgQtOF4ykq3dgcjv85kuOtp0xcnow4hw358hE6bK0Wo/oAOfnyBYGrPUIQRw uNSgJdK4KBfKepGXvCs/qEorWdj0Jv+ZzjmkLOhOykZDRfRyZrfbw7LtKfEx74R5Mlr8 AG9w== X-Received: by 10.180.74.162 with SMTP id u2mr36729514wiv.0.1438099363145; Tue, 28 Jul 2015 09:02:43 -0700 (PDT) Received: from volcano.localdomain (host-89-243-102-238.as13285.net. [89.243.102.238]) by smtp.googlemail.com with ESMTPSA id b13sm19692011wic.15.2015.07.28.09.02.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 09:02:41 -0700 (PDT) To: Eric Dumazet , Simon Barber 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> <1438094970.20182.53.camel@edumazet-glaptop2.roam.corp.google.com> From: Alan Jenkins Message-ID: <55B7A7A0.2030605@gmail.com> Date: Tue, 28 Jul 2015 17:02:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1438094970.20182.53.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:03:14 -0000 On 28/07/15 15:49, Eric Dumazet wrote: > On Tue, 2015-07-28 at 07:31 -0700, 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. > As I said, I've never seen what you describe. > > 100ms value is not a go/nogo threshold. It is a hint, based on real > world values. We are speaking of 100 ms sojourn time in the CoDel queue, > not sojourn time in the Internet ! > > You can still have flows with 500 ms or even 10 sec rtt and codel just > works fine. > > Are you sure you understood how this was working ? > The codel paper indicates utilization dropoff as RTT increases above the 'interval' (and that interval is set based on expected rtt). They presented an average of several loads, so this wasn't even the single-stream worst case. 200ms rtt was fine, 500ms was a slightly worse & varied a lot more. If you wanted something that was "fine" at 10s (ow), you wouldn't want codel's defaults. Tuning higher values in fq_codel would probably be enough though. http://queue.acm.org/detail.cfm?id=2209336