From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 E730C21F25F for ; Mon, 24 Mar 2014 17:18:28 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id uo5so6184156pbc.32 for ; Mon, 24 Mar 2014 17:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; bh=FEZglit6Bd9yGmskm5M0iHv8O7SBK9a+C2qBAbh3U80=; b=A+OcnPOy30T3vEuCi+w+s0HNUf6t0b/uN+r5qwnTVY0gTO4fyASLV7BPUHuU0vNzJM cTlx8gjM6P8VZn3RGFii9zOrl+S4+N9PA3f3SIHNTaytEOqmzxVymot70xzoMb59nPVU gjtz1S00ohwxW5Hgn8AAkiF2hqaztFF1CbkGKzMNUgyIdiBN193+pLJ8UX7HGY8kVrVZ eJQk0sIaI4AgtX9Ww+DBjDCnJ4lZ9orfZj47hxe9T/vrrPqDj6tBoukAZdR5yGatDHI3 VHzShez9cdkT8J40FEx+jRGoh80f7xUA0jI9LXYYY0GQqFKd0XZwFnB+XrjsSJ95BSOf Ia6g== X-Received: by 10.68.93.3 with SMTP id cq3mr7331499pbb.145.1395706708519; Mon, 24 Mar 2014 17:18:28 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3e02:24c4:1b92:9759:b60a? ([2620:0:1000:3e02:24c4:1b92:9759:b60a]) by mx.google.com with ESMTPSA id vb7sm36690216pbc.13.2014.03.24.17.18.27 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 24 Mar 2014 17:18:28 -0700 (PDT) Message-ID: <1395706707.12610.101.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Dave Taht Date: Mon, 24 Mar 2014 17:18:27 -0700 In-Reply-To: References: <1395682887.12610.62.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: "Steinar H. Gunderson" , bloat Subject: Re: [Bloat] Replacing pfifo_fast? (and using sch_fq + hystart fixes) 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, 25 Mar 2014 00:18:29 -0000 On Mon, 2014-03-24 at 16:10 -0700, Dave Taht wrote: > One of my concerns is that sch_fq is (?) currently inadaquately > explored in the case of wifi - as best as I recall there were a > ton of drivers than cloned and disappeared the skb deep > in driver buffers, making fq_codel a mildly better choice... Thats because fq_codel do not add delays (other than RR scheduling among flows). Remember, if no queue is in fq_codel itself, there nothing we can control using codel law. In the fq case, packets are held in the qdisc the needed time and delivered 'at the right time' to whatever lower device. Part of the 'original TCP bursts' are amortized by sch_fq before reaching device. TCP pacing has nothing to do with additional delays imposed in various wifi drivers. Consider a packet in wifi queue exactly as if it was already sent on the network.