From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 C170F21FA99 for ; Wed, 29 Jul 2015 04:36:35 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so22061383wib.1 for ; Wed, 29 Jul 2015 04:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=mGajCcskhSqeDa+R95HXt/pz7vvNjf5ej7JE4USvVTc=; b=jyuOfmeO3YI/o0YkMmTOGzbx0oENq99xTpvLAgco4XSJGONOhWx5BcKz+pWzH6vYVQ bc7E241uPshYJAkK+G9VAWerrKYtt9eRGcWpN2VcLGZUEwAl+ft86fw4MsfwEqDCDGYn x2bOzlqTz75R590CrQgcRvg1pM688qgMMngFfrakLTXqxWBcjNbcT2HgR7FCtftOWhXY 949eA02kL3YugkKJ2gnzx8rX7mHdZIPi6zcDLbiRqqQXfJIjd+mN7ojGxnB0bF6gkg73 JzGrdImxlr4l0zTJL651EAtn5DI1YFENEXd8+RHK3IkKXLZbk7ijwOmeToiBAy+W7yCF GA7A== X-Received: by 10.194.61.175 with SMTP id q15mr34993846wjr.135.1438169793519; Wed, 29 Jul 2015 04:36:33 -0700 (PDT) Received: from volcano.localdomain (host-89-243-101-162.as13285.net. [89.243.101.162]) by smtp.googlemail.com with ESMTPSA id z9sm23918852wiv.9.2015.07.29.04.36.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 04:36:32 -0700 (PDT) To: Rosen Penev , bloat@lists.bufferbloat.net References: <55B8B7EE.3070401@gmail.com> From: Alan Jenkins Message-ID: <55B8BABF.8040708@gmail.com> Date: Wed, 29 Jul 2015 12:36:31 +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: <55B8B7EE.3070401@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 11:37:04 -0000 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 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 :). > Flent can do this test and generate pretty graphs, including a time > series (plot type "all_scaled") and frequency distribution for the > ping ("ping_cdf"). Flent is a frontend to the netperf network > performance tester. You could use a directly connected laptop and run > your own netperf server (netserver command). You'll need to set up > static IPs on both ends for the duration... if headless then make sure > you have an alternative console access :). > > The normal Flent test is RRUL, which is two-way. tcp_2up would be > better, to avoid testing both end's BQL at the same time. If you want > to run tcp_2up the other way round, so you only need netserver on the > ARM, try using '--swap-up-down'. > > Alan