From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 81476201B52 for ; Fri, 31 Aug 2012 09:49:09 -0700 (PDT) Received: by lbol12 with SMTP id l12so2878432lbo.16 for ; Fri, 31 Aug 2012 09:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RcdpB9uw40B3Y/aB0R9bMR6S/EtTcGqCv7RZa+ve8Sk=; b=h2jI4/rzz0mK7Vzkt4/XLABgNLigH0OzN75ZxgucXcSxmiwakWRuT+clOIZStwXO5V hQ7vO9euJ/YEE3LO6WqlT+w7Qw799iNMCDOesZxTTKTkcxImya71Hc3Xk3GC8FL4pyCo +1ILqlOu9I/50an5KPORHtJuSpUMv25pCA1oEqIzjCPXk20nhpsJLRogCcDM1v5w7v9u NNYwOTqfIp9cmS60DOWbeaiqdLAmGcwjd8cimqW28qbTn0rUhdGCR9v0gjbqseSvAFJ2 hKsF8EDuwX5pJ0bJYC/2LmZMZxoSZ98cAcGRj3251VsXNEcRfVrd/h8g2rGAWR+7cLQk xo5w== Received: by 10.112.26.73 with SMTP id j9mr1018880lbg.10.1346431746656; Fri, 31 Aug 2012 09:49:06 -0700 (PDT) Received: from bass.home.chromatix.fi (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id hz16sm5215535lab.6.2012.08.31.09.49.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 09:49:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <5040E8EE.2070900@freedesktop.org> Date: Fri, 31 Aug 2012 19:49:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <187CE1B3-6772-4E1C-A983-3AEC637C04FE@gmail.com> References: <1346396137.2586.301.camel@edumazet-glaptop> <5040DDE9.7030507@hp.com> <5040E8EE.2070900@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) 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 16:49:10 -0000 On 31 Aug, 2012, at 7:40 pm, Jim Gettys wrote: > On 08/31/2012 08:53 AM, Rick Jones wrote: >> 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) >>>=20 >>> Datacenter workload benefits using shorter feedback (say if RTT is = below >>> 1 ms, we can react 100 times faster to a congestion) >>>=20 >>> Idea from Yuchung Cheng. >>=20 >> Mileage varies of course, but what are the odds of a datacenter's >> end-system's NIC(s) being the bottleneck point? > Ergo my comment about Ethernet flow control finally being possibly = more > help than hurt; clearly if the bottleneck is kept in the sending host > more of the time, it would help. >=20 > I certainly don't know how often the end-system's NIC's are the > bottleneck today without flow control; maybe a datacenter type might > have insight into that. Consider a fileserver with ganged 10GE NICs serving an office full of = GigE workstations. At 9am on Monday, everyone arrives and switches on their workstation, = which (because the org has made them diskless) causes pretty much the = same set of data to be sent to each in rapid succession. The fileserver = satisfies all but the first of these from cache, so it can saturate all = of it's NICs in theory. In that case a queue should exist even if there = are no downstream bottlenecks. Alternatively, one floor at a time boots up at once - say the = call-centre starts up at 7am, the developers stumble in at 10am, and the = management types wander in at 11:30. :-) Then the bottleneck is the = single 10GE link to each floor, rather than the fileserver's own NICs. That's all theoretical, of course - I've never built a datacentre = network so I don't know how it's done in practice. - Jonathan Morton