From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E4E7E21F18A for ; Tue, 25 Feb 2014 05:37:37 -0800 (PST) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LvhC4-1XIvL82Iqi-017TaA for ; Tue, 25 Feb 2014 14:37:34 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 25 Feb 2014 14:37:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34C9F2ED-49BD-43DF-8421-67D1D3CBA5E1@gmx.de> References: <4E5BC321-2054-4364-BECC-DF34E0D20380@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:X4YvGRAYqdNsQpMSzdaazZvxSkcZuF1E1NfGBN1AR8H431TaBdZ Id3Wsi2BxP93d1FuWAlLu1It5t8MXQHPGQicdIoG2ehiK1utTQjb7YyFd4xe7m1/TOp5/PY O7+daEjkwKBOWB8rG0xOiClhI1bUc1lx4EvE2gOHVt4JOQctQxgoE6rh7w/2yGe1LpJUE6W +ox2xNtljuU+kFGxmY1hA== 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: Tue, 25 Feb 2014 13:37:38 -0000 Hi Rich, On Feb 25, 2014, at 14:09 , Rich Brown wrote: > Thanks everyone for all the good advice. I will summarize my responses = to all your notes now, then I'll go away and run more tests. >=20 > - Yes, I am using netperf 2.6.0 and netperf-wrapper from Toke's github = repo. >=20 > - The "sync rate" is the speed with which the DSL modem sends bits = to/from my house. I got this by going into the modem's admin interface = and poking around. (It turns out that I have a very clean line, high = SNR, low attenuation. I'm much less than a km from the central office.) = So actual speed should approach this, except=85 I would think of this as the theoretical upper limit ;) >=20 > - Of course, I have to subtract all those overheads that Sebastian = described - ATM 48-in-53, which knocks off 10%; ATM frame overhead which = could add up to 47 bytes padding to any packet, etc.) >=20 > - I looked at the target calculation in Dave's Home Gateway best = practices. = (http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practic= es-00.html) Am I correct that it sets the target to five 1500-byte = packet transmission time or 5 msec, whichever is greater? Note, the auto target implementation in ceropackages-3.10 = sqm-scripts uses the following: adapt_target_to_slow_link() { CUR_LINK_KBPS=3D$1 CUR_EXTENDED_TARGET_US=3D MAX_PAKET_DELAY_IN_US_AT_1KBPS=3D$(( 1000 * 1000 *1540 * 8 / 1000 )) CUR_EXTENDED_TARGET_US=3D$(( ${MAX_PAKET_DELAY_IN_US_AT_1KBPS} / = ${CUR_LINK_KBPS} )) # note this truncates the decimals # do not change anything for fast links [ "$CUR_EXTENDED_TARGET_US" -lt 5000 ] && = CUR_EXTENDED_TARGET_US=3D5000 case ${QDISC} in *codel|pie) echo "${CUR_EXTENDED_TARGET_US}" ;; esac } This is modeled after the shell code Dave sent around, and does not = exactly match the free version, because I could not make heads and tails = out of the free version. (Happy to discuss change this in SQM if anybody = has a better idea) >=20 > - I was astonished by the calculation of the bandwidth consumed by = acks in the reverse direction. In a 7mbps/768kbps setting, I'm going to = lose one quarter of the reverse bandwidth? Wow! Well, so was I (first time I did that) but here is the kicker = with classical non0-delayed ACKs this actually doubles since each data = packet gets acknowledged (I assume this puts a lower bound on how = asymmetrical a loin an ISP can sell ;) ). But since I figured out that = macosx seems to default to 1 Ack for every 4 packets, so only half the = traffic. And note any truly bi-directional traffic shouldbe able to = piggyback many of those ACKs into normal data packets. >=20 > - I wasn't entirely clear how to set the target in the SQM GUI. I = believe that "target ##msec" is an acceptable format. Is that correct? In the new version with the dedicated target field, "40ms" will = work as will "40000us", "40 ms". In the most recent version "auto" will = set the auto adjustment of target (it will also extend interval by the = new-target - 5ms) to avoid the situation where Target gets larger than = interval. In the older versions you would put "target 40ms" into the = egress advanced option string. Note I used double quotes in my examples = for clarity, the GUI does not want those... >=20 > - There's also a discussion of setting the target with "auto", but I'm = not sure I understand the syntax. just type in auto. You can check with log read and "tc -d qdsic" Best Regards Sebastian >=20 > Now to find some time to go back into the measurement lab! I'll report = again when I have more data. Thanks again. >=20 > Rich >=20 >=20 >=20 > On Feb 24, 2014, at 9:56 AM, Aaron Wood wrote: >=20 >> Do you have the latest (head) version of netperf and netperf-wrapper? = some changes were made to both that give better UDP results. >>=20 >> -Aaron >>=20 >>=20 >> On Mon, Feb 24, 2014 at 3:36 PM, Rich Brown = wrote: >>=20 >> CeroWrt 3.10.28-14 is doing a good job of keeping latency low. But... = it has two other effects: >>=20 >> - I don't get the full "7 mbps down, 768 kbps up" as touted by my DSL = provider (Fairpoint). In fact, CeroWrt struggles to get above 6.0/0.6 = mbps. >>=20 >> - When I adjust the SQM parameters to get close to those numbers, I = get increasing levels of packet loss (5-8%) during a concurrent ping = test. >>=20 >> 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 getting close to the link capacity should induce large packet = loss... >>=20 >> Experimental setup: >>=20 >> I'm using a Comtrend 583-U DSL modem, that has a sync rate of 7616 = kbps down, 864 kbps up. Theoretically, I should be able to tell SQM to = use numbers a bit lower than those values, with an ATM plus header = overhead with default settings. >>=20 >> I have posted the results of my netperf-wrapper trials at = http://richb-hanover.com - There are a number of RRUL charts, taken with = different link rates configured, and with different link layers. >>=20 >> I welcome people's thoughts for other tests/adjustments/etc. >>=20 >> Rich Brown >> Hanover, NH USA >>=20 >> 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. >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel