From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C212F21F0C6; Wed, 16 May 2012 00:47:03 -0700 (PDT) Received: by bkty5 with SMTP id y5so728374bkt.16 for ; Wed, 16 May 2012 00:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=EujUhBnIG127YSTY61bKNfuI5YozF78h4tEuZ7n7ly8=; b=FAVIwxFXE2I987FDLzm/Y2cp2iNktOyiRLALK2Ucrl6XRNFKdt1/KSJollOpuXaGrj ZRMOAgzzI1vYPgLN8RrtzhejnmaWt7BMlCQDr342Z1M7tOaBr+uY4fnYc5hx1089E2JO HTWexEF/aeJQuP2Ay4BpDzdDZYA/CgllUd9l5WkfkmR9kXct/msaMemNtvR6puFn4PZS ZRTgyzWwfPyC8rmHKcH1ESgbN7DBslhGk/53FMcN8ZNiArENF7f5OihMDlyyUfpgMTBM lbtm3Fdm71Q0d5WCAQqVTRxnop2TeYXP5uuFTcM2oz1qjyAcp/vc7pt7k8aMQCN9oLub 2Hbg== Received: by 10.204.148.75 with SMTP id o11mr781251bkv.11.1337154421678; Wed, 16 May 2012 00:47:01 -0700 (PDT) Received: from [172.28.91.41] ([74.125.122.49]) by mx.google.com with ESMTPS id f11sm2755408bkw.6.2012.05.16.00.46.59 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 00:47:00 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: <4FA9FDC0.9010600@superduper.net> <1337148560.8512.1123.camel@edumazet-glaptop> <4FB3519D.3020809@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 May 2012 09:46:57 +0200 Message-ID: <1337154417.8512.1147.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Codel] [Bloat] Exploring the potential of codel, fq_codel, and qfq X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 07:47:04 -0000 On Wed, 2012-05-16 at 00:20 -0700, Dave Taht wrote: > With ecn: > > 64 bytes from 149.20.63.18: icmp_req=46 ttl=64 time=10.6 ms > 64 bytes from 149.20.63.18: icmp_req=47 ttl=64 time=5.66 ms > 64 bytes from 149.20.63.18: icmp_req=48 ttl=64 time=11.8 ms > 64 bytes from 149.20.63.18: icmp_req=49 ttl=64 time=3.68 ms > 64 bytes from 149.20.63.18: icmp_req=50 ttl=64 time=10.2 ms > 64 bytes from 149.20.63.18: icmp_req=51 ttl=64 time=12.8 ms > 64 bytes from 149.20.63.18: icmp_req=52 ttl=64 time=2.62 ms > 64 bytes from 149.20.63.18: icmp_req=53 ttl=64 time=7.86 ms > > TCP_RR: 102 > > All of these sets of results need more rigor attached. On TCP_RR pure workload, you have one packet in flight per flow. ECN adds nothing in this case, only that no 'drops' occurs at all. It might be good to change fq_codel to perform ECN mark only if flow queue has more packets. If not, plain drop.