From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 3F3CA21F371 for ; Wed, 29 Jul 2015 10:42:17 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so12786113obd.0 for ; Wed, 29 Jul 2015 10:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X9Q4gvDl8il3+UWvLtCg6PTmPYQIsSqRoPHwyDBBJmg=; b=BnczcAj3TtfsLY+a3Q88p+6lrSCZ4dMoam+cz6yNG6gKtleRafV79ZANkmPmIHCPBx B2VUD64tvRh7tZuMMzP0iUuf19LeCISHQrWlajX784cAgoYyW82WHz5ac7AqTe/5CY2g S1LPFaXZ8Ep7j6umcF8j1T8TlXckU/LdNWyZypSckfzy0LgLnZEqX1OLRHxxQKeTYlkY DYTfqIGQnI68KaVlPYzRot+UAcZ8feBopLU3w4C92JkgLzGBbn/cOpX/d2YbkZQ6ystc 6YmJ5EfjPSs0uI1G9S7HGxCZQUtunchU9qWcImEs7gMj63kwphya2DXxW6A92VIZpY3f nbdA== MIME-Version: 1.0 X-Received: by 10.182.158.164 with SMTP id wv4mr43435990obb.78.1438191737075; Wed, 29 Jul 2015 10:42:17 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Wed, 29 Jul 2015 10:42:17 -0700 (PDT) In-Reply-To: References: <55B8B7EE.3070401@gmail.com> <55B8BABF.8040708@gmail.com> Date: Wed, 29 Jul 2015 19:42:17 +0200 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 17:42:46 -0000 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 network= ing >>> 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 qdi= sc is >>> set to fq_codel. fq_codel effectively prioritizes ping, so the differe= nce >>> 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 t= he > queue lengths that are allowed, the queue length should be much higher wi= th > 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 t= he >>> 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 tes= t >>> those speeds even if you can do better though). You probably also want= to >>> start with offloads (tso, gso, gro) disabled using ethtool, because the= y >>> 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. > > 8ms of latency under load is doing very well. what are you expecting? > > David Lang > > >>> 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 net= perf >>> server (netserver command). You'll need to set up static IPs on both e= nds >>> 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 >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast