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 did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 82129201261 for ; Tue, 4 Sep 2012 08:39:16 -0700 (PDT) Received: by bkty15 with SMTP id y15so4051466bkt.16 for ; Tue, 04 Sep 2012 08:39:14 -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=1vuqFFOJdRQZbPPa10c66+VudjJY71qtD1nPWDR3LWI=; b=gw2BF7G6nfPTsvD+uPmj6vWC8T5o+nh3HMVgvFvp+VG+XstfVLU3YLByk/+DF3RVs5 K+kk7KMQRJ8L1zY93WgM7P0a2Cs5+AXIjhThyiyxEZlnjANAlEcsw74E/ejtTg7fhbgN ytxiX5jD8kxaKi5YvH3eIBvlfOUdMn2/DjJEZA8QQfKbgCCMcYZe2CtRMD+l8AUrvdwa 6KXQ0XYoxsZIVRfmhxg7FUSfV/4xojR2No5uYeDxoGRGKXo2lK0g4BVFhoFCE0WWdapj L2RN3b1Y+xmDxP/c+vSYt4iJWMr4KXYktplit5+toTcM5jg+AJVinFtlFVaMXmD3lKtW dkAw== Received: by 10.204.9.194 with SMTP id m2mr8179808bkm.132.1346773154545; Tue, 04 Sep 2012 08:39:14 -0700 (PDT) Received: from [192.168.142.158] ([74.125.121.33]) by mx.google.com with ESMTPS id y20sm10779590bkv.11.2012.09.04.08.39.11 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 08:39:12 -0700 (PDT) From: Eric Dumazet To: Jonathan Morton In-Reply-To: <1C18E243-42BC-46F0-A336-EAD9BC881C45@gmail.com> References: <1346396137.2586.301.camel@edumazet-glaptop> <1346421031.2591.34.camel@edumazet-glaptop> <1346421466.2591.38.camel@edumazet-glaptop> <1346503884.7996.65.camel@edumazet-glaptop> <1C18E243-42BC-46F0-A336-EAD9BC881C45@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 04 Sep 2012 17:39:09 +0200 Message-ID: <1346773149.13121.44.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Nandita Dukkipati , netdev , "codel@lists.bufferbloat.net" , Tomas Hruby Subject: Re: [Codel] [RFC v2] fq_codel : interval servo on hosts 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: Tue, 04 Sep 2012 15:39:17 -0000 On Tue, 2012-09-04 at 18:25 +0300, Jonathan Morton wrote: > I think that in most cases, a long RTT flow and a short RTT flow on > the same interface means that the long RTT flow isn't bottlenecked > here, and therefore won't ever build up a significant queue - and that > means you would want to track over the shorter interval. Is that a > reasonable assumption? > This would be reasonable, but if we have a shorter interval, this means we could drop packets of the long RTT flow sooner than expected. Thats because the drop_next value is setup on the previous packet, and not based on the 'next packet' Re-evaluating drop_next at the right time would need more cpu cycles.