From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 5E7B421F83B for ; Fri, 26 Jun 2015 11:24:43 -0700 (PDT) Received: by oigb199 with SMTP id b199so81353389oig.3 for ; Fri, 26 Jun 2015 11:24:43 -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=aOHyXbzyCPJq2yG0c8xc3j16EhxWQLqdEmMTK+U/R+w=; b=Hv3exkUWPvKyJYt7PxhpKSRv2ZZSVwwSAI/TRaDrPnCKqlvszZLE4t6qIg2LybiLFn LCe9UXwCEDxQhKwA9v94NdbKP0zcWXYFOVAroI5BaXBDfHWkUJOekv6zLP9d8BUEbH9U e7Tdhsyd/tYjssVlRmS0A2mTxYGcBPBnXsUkJOT0eb1V2IMEvofaVrLNbA2rEnmN36xh VaCmhvkl1HyLq7SQRFX4KjKFqee+5GIBrv/hoiwapBjn37ODQCywgtUtaLou3a3AuzmH 8fpCybt4NkQ4bkSLEQmTPYDRrVfWh57i9NqYuWF4gNYm60Ak+rcFcHyWasRzIO0ft9to 1bsg== MIME-Version: 1.0 X-Received: by 10.202.66.196 with SMTP id p187mr2518745oia.133.1435343083386; Fri, 26 Jun 2015 11:24:43 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Fri, 26 Jun 2015 11:24:43 -0700 (PDT) In-Reply-To: References: <55847E32.9000405@gmail.com> <5584823E.4040207@gmail.com> <0129B5FB-9D1B-45FF-84CA-492A6A0B638B@gmx.de> <43D5C3CE-F1F4-4BA5-AEB9-55348661C7BA@gmx.de> Date: Fri, 26 Jun 2015 11:24:43 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] performance numbers from WRT1200AC (Re: Latest build test - new sqm-scripts seem to work; "cake overhead 40" didn't) X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:25:12 -0000 Mikael, a simple test of the analysis I just did would be to use ethtool to set your server to 100mbits (ethtool -s your_ethernet_device advertise 0x008 and turn on fq_codel on both the client and server. if it is using classification for the hw mq, the rrul test from the client will blow up half the queues. If it is doing hw fq instead, the rrul_50_up test will blow up all 8 queues. For giggles, try 0x002 (10mbit) my own attempts to get a compile for this platform consistently blow up here similarly for both musl and uclibc. checking for arm-openwrt-linux-muslgnueabi-gcc... /build/cero3/src/ac1900/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-lin= aro_musl-1.1.10_eabi/gcc-linaro-4.8-2014.04-minimal/./gcc/xgcc -B/build/cero3/src/ac1900/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-l= inaro_musl-1.1.10_eabi/gcc-linaro-4.8-2014.04-minimal/./gcc/ -B/build/cero3/src/ac1900/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8= -linaro_musl-1.1.10_eabi/arm-openwrt-linux-muslgnueabi/bin/ -B/build/cero3/src/ac1900/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8= -linaro_musl-1.1.10_eabi/arm-openwrt-linux-muslgnueabi/lib/ -isystem /build/cero3/src/ac1900/staging_dir/toolchain-arm_cortex-a9+vfpv3_= gcc-4.8-linaro_musl-1.1.10_eabi/arm-openwrt-linux-muslgnueabi/include -isystem /build/cero3/src/ac1900/staging_dir/toolchain-arm_cortex-a9+vfpv3_= gcc-4.8-linaro_musl-1.1.10_eabi/arm-openwrt-linux-muslgnueabi/sys-include checking for suffix of object files... configure: error: in `/build/cero3/src/ac1900/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-li= naro_musl-1.1.10_eabi/gcc-linaro-4.8-2014.04-minimal/arm-openwrt-linux-musl= gnueabi/libgcc': configure: error: cannot compute suffix of object files: cannot compile On Fri, Jun 26, 2015 at 10:04 AM, Dave Taht wrote: > On Fri, Jun 26, 2015 at 9:35 AM, Jonathan Morton = wrote: >> These would be hardware tail drops - there might not be a physical count= er >> recording them. But you could instrument three driver to see whether the >> receive buffer is full when serviced. > > from drivers/net/ethernet/marvel/mvneta.c: > > /* Max number of Rx descriptors */ > #define MVNETA_MAX_RXD 128 > > this is probably too small, especially given the 64 it is willing to > wait for. At the same time, it is too large, as there are 8 hardware > queues in play here. So you get a huge burst from one flow, it gros it > all together.... aggghh... > > /* Max number of Tx descriptors */ > #define MVNETA_MAX_TXD 532 > > this realllllly needs BQL. Same problem(s). Only worse. > > >> >> - Jonathan Morton >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > -- > 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 --=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