From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 1FAF521F1EF for ; Mon, 24 Feb 2014 07:52:00 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so2924585wgh.5 for ; Mon, 24 Feb 2014 07:51:59 -0800 (PST) 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=AiEhATtgAR2TfbtPHlL3wnPVeeyfo0//wHx4Bhl5xNA=; b=BTg95Il3CK0/JfwFG1lcpufv3+3Blwkx3lYHUovpW+tXcoEkLx8JevJ7vUOOzBgQG9 e5CHz3sBg0GclTzs3pScW1roYxVFg32OIk682qdqefmfmIGmPpATpDIk61cFPMqWFpFy c2CSiotTSg1/namC2z6a6NrEmICad9lrcl9y1uSZSsCD0ggANWdjNHgtHO1UKl3xpvoq YkYaG8qN1c2sknilu0wZaBNMdeepWCwO4z2YbQStunIhaB7GrEhPzNTCGmxoyPppXR8x nnNGa2EhyDZ2w1K2jCUWA/vaDY3L4YLxJEf3iG69rbnB/w1M2/vGhf2h2/bW295aS52u FPPg== MIME-Version: 1.0 X-Received: by 10.194.90.144 with SMTP id bw16mr19335916wjb.1.1393257119241; Mon, 24 Feb 2014 07:51:59 -0800 (PST) Received: by 10.216.8.1 with HTTP; Mon, 24 Feb 2014 07:51:59 -0800 (PST) In-Reply-To: <4E5BC321-2054-4364-BECC-DF34E0D20380@gmail.com> References: <4E5BC321-2054-4364-BECC-DF34E0D20380@gmail.com> Date: Mon, 24 Feb 2014 10:51:59 -0500 Message-ID: From: Dave Taht To: Rich Brown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] Equivocal results with using 3.10.28-14 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: Mon, 24 Feb 2014 15:52:01 -0000 On Mon, Feb 24, 2014 at 9:36 AM, Rich Brown wrote= : > > CeroWrt 3.10.28-14 is doing a good job of keeping latency low. But... it = has two other effects: > > - I don't get the full "7 mbps down, 768 kbps up" as touted by my DSL pro= vider (Fairpoint). In fact, CeroWrt struggles to get above 6.0/0.6 mbps. 0) try the tcp_upload or tcp_download or tcp_bidir tests to get results closer to what your provider claims. since your plots are pretty sane, you can get cleaner ones with using the 'totals' plot type and/or comparing multiple runs to get a cdf -p totals or -p icmp (theres a few different ones, --list-plots -i somerun.json.gz -i somerun2.json.gz 1) http://richb-hanover.com/wp-content/uploads/2014/02/6854-777-dflt-sqm-di= sabled1.png is your baseline without SQM? If so why do you compare the providers stated rate... with the measured rate with/without SQM? These are two measures of the truth - one with and without a change. Vs a providers claim for link rate that doesn't account for real packet dynamics. 2) the netperf reporting interval is too high to get good measurements at below a few mbit, so you kind of have to give up on the upload chart at these rates. (totals chart is clearer) Note that the tcp acks are invisible - you are getting >6mbit down, and sending back approximately 150kbit in acks which we can't easily measure. The overhead in the measurement streams is relative to the RTT as well. I'd really like to get to a test that emulated tcp and got a fully correct measurement. 3) Generally using a larger fq_codel target will give you better upload throughput and better utiliziation at these rates. try target 40ms as a start. We've embedded a version of the calculation in the latest cero build attempts (but other stuff is br= oke) nfq_codel seems also do to give a better balance between up and downloads at low rates, also with a larger target. it looks like overhead 44 is about right and your first set of charts about right. > > - When I adjust the SQM parameters to get close to those numbers, I get i= ncreasing levels of packet loss (5-8%) during a concurrent ping test. Shows the pings are now accruing delay. > > So my question to the group is whether this behavior makes sense: that we= can have low latency while losing ~10% of the link capacity, or that getti= ng close to the link capacity should induce large packet loss... You never had the 10% in the first place. > > Experimental setup: > > I'm using a Comtrend 583-U DSL modem, that has a sync rate of 7616 kbps d= own, 864 kbps up. Theoretically, I should be able to tell SQM to use number= s a bit lower than those values, with an ATM plus header overhead with defa= ult settings. > > I have posted the results of my netperf-wrapper trials at http://richb-ha= nover.com - There are a number of RRUL charts, taken with different link ra= tes configured, and with different link layers. > > I welcome people's thoughts for other tests/adjustments/etc. > > Rich Brown > Hanover, NH USA > > PS I did try the 3.10.28-16, but ran into troubles with wifi and ethernet= connectivity. I must have screwed up my local configuration - I was doing = it quickly - so I rolled back to 3.10.28.14. manually adjust the target. > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html