From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6C7CE21F0AC for ; Fri, 31 Aug 2012 08:53:17 -0700 (PDT) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 7399C3803D; Fri, 31 Aug 2012 15:53:15 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id E32D410002; Fri, 31 Aug 2012 15:53:14 +0000 (UTC) Message-ID: <5040DDE9.7030507@hp.com> Date: Fri, 31 Aug 2012 08:53:13 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Eric Dumazet References: <1346396137.2586.301.camel@edumazet-glaptop> In-Reply-To: <1346396137.2586.301.camel@edumazet-glaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] fq_codel : interval servo 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: Fri, 31 Aug 2012 15:53:17 -0000 On 08/30/2012 11:55 PM, Eric Dumazet wrote: > On locally generated TCP traffic (host), we can override the 100 ms > interval value using the more accurate RTT estimation maintained by TCP > stack (tp->srtt) > > Datacenter workload benefits using shorter feedback (say if RTT is below > 1 ms, we can react 100 times faster to a congestion) > > Idea from Yuchung Cheng. Mileage varies of course, but what are the odds of a datacenter's end-system's NIC(s) being the bottleneck point? Is it worth pinging a couple additional cache lines around (looking at the v2 email, I'm ass-u-me-ing that sk_protocol and tp->srtt are on different cache lines)? If fq_codel is going to be a little bit pregnant and "layer violate" :) why stop at TCP? Is this change rectifying an "unfairness" with the existing fq_codel and the 100ms for all when two TCP flows have very different srtts? Some perhaps overly paranoid questions: Does it matter that the value of tp->srtt at the time fq_codel dequeues will not necessarily be the same as when that segment was queued? Is there any chance of the socket going away between the time the packet was queued and the time it was dequeued? (Or tp->srtt becoming "undefined?") rick jones