From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 903D921FA98 for ; Wed, 29 Jul 2015 11:56:45 -0700 (PDT) Received: by wibud3 with SMTP id ud3so232464663wib.1 for ; Wed, 29 Jul 2015 11:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=PHUd8wHOCBgyJbhRp8fv2O8PIV/ZXq+miTzYyYNUlvg=; b=rkRJMz/t07ZG+bbckKly4u5hOvuTSs2ChlYef6hzL0PeGQlYgAgIKNNNFmu8NBP0XD 8lwSSBtZ/5qdepgKik5qSh9glGd1fsT3Xezn9vOQ9PcthZjR3NgSQbUHsILer9yExJ6D C7uhSvmnkGQ2I2dd5eqXQQMSc82lMfgD0uppQOHQ+7DpE8TzUgUdHc/uHvPJ1riRxi58 buBbeBYuIN2afF7f5gSBHGwusxTLJOHZLmpdTn4nGkQkrr9mMMsLT8QrCIKpvA0HcRd8 NJAj27pwwjXIXto6YUjc1wqEZlRSedrB5m9EK3KPlp0tC316FVnlqoFua6kh9FXPXl0N wUog== X-Received: by 10.195.11.3 with SMTP id ee3mr80006992wjd.89.1438196203605; Wed, 29 Jul 2015 11:56:43 -0700 (PDT) Received: from volcano.localdomain (host-89-243-101-162.as13285.net. [89.243.101.162]) by smtp.googlemail.com with ESMTPSA id be9sm39941410wjb.26.2015.07.29.11.56.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 11:56:42 -0700 (PDT) To: Dave Taht , David Lang References: <55B8B7EE.3070401@gmail.com> <55B8BABF.8040708@gmail.com> From: Alan Jenkins Message-ID: <55B921E9.9060105@gmail.com> Date: Wed, 29 Jul 2015 19:56:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] Kirkwood BQL? 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: Wed, 29 Jul 2015 18:57:14 -0000 On 29/07/15 18:42, Dave Taht wrote: > On Wed, Jul 29, 2015 at 7:07 PM, David Lang wrote: >> On Wed, 29 Jul 2015, Alan Jenkins wrote: >> >>> On 29/07/15 12:24, Alan Jenkins wrote: >>>> On 29/07/15 05:32, Rosen Penev wrote: >>>>> Anyone know what the situation is with kirkwood and BQL? I found a >>>>> patch for it but have no idea if there are any issues. >>>>> >>>>> I have such a system but have no idea how to ascertain the efficacy of >>>>> BQL. >>>> >>>> To the latter: >>>> >>>> BQL works for transmissions that reach the full line rate (e.g. for >>>> 1000MB ethernet). It limits the queue that builds in the driver/device to >>>> the minimum they need. Then queue mostly builds in the generic networking >>>> stack, where it can be managed effectively e.g. by fq_codel. >>>> >>>> So a simple efficacy test is to run a transmission at full speed, and >>>> monitor latency (ping) at the same time. Just make sure the device qdisc is >>>> set to fq_codel. fq_codel effectively prioritizes ping, so the difference >>>> will be very easy to see. >>>> >>>> I don't know if there's any corner cases that want testing as well. >> >> BQL adjusts the number of packets that can be queued based on their size, so >> you can have far more 64 byte packets queued than you can have 1500 byte >> packets. >> >> do a ping flood of your network with different packet sizes and look at the >> queue lengths that are allowed, the queue length should be much higher with >> small packets. >> >>>> BQL can be disabled at runtime for comparison testing: >>>> http://lists.openwall.net/netdev/2011/12/01/112 >>>> >>>> There's a BQL tool to see it working graphically (using readouts from the >>>> same sysfs directory): >>>> https://github.com/ffainelli/bqlmon >>>> >>>> My Kirkwood setup at home is weak, I basically never reach full link >>>> speed. So this might be somewhat academic unless you set the link speed to >>>> 100 or 10 using the ethtool command. (It seems like a good idea to test >>>> those speeds even if you can do better though). You probably also want to >>>> start with offloads (tso, gso, gro) disabled using ethtool, because they >>>> aggregate packets. >>>> >>> a quick test with a 100M setting, connected to gigabit switch, and flent >>> tcp_download, shows ping under load increases to about 8ms. Conclusion: the >>> Debian kirkwood kernel probably isn't doing BQL for me :). > Wrong way I think. Try tcp_upload. "flent tcp_download" running on the connected x86 laptop. So I didn't have to use Flent on the Kirkwood device, only netperf's netserver.