From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id DBC9E21F1EA for ; Wed, 14 Aug 2013 07:28:06 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E79EC21330; Wed, 14 Aug 2013 10:28:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 14 Aug 2013 10:28:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h= content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s=mesmtp; bh=EwEwxBdsmLIhg/Ik8QlDPdujXss=; b=RmRWichh4GGoCwZkWRyJZ/CgdTYx qQdcVr6KM3635aISiCyGiv3DToHq8PXftFNxJJoFFWSjjab4MQp9iYYI0vcUTEKe iY7S7QGHx9PyR/jZqq+h0c49VUKlOQQy91ZsoeWJo6JoK2gi9Sg/kJew9e5pHF5I w4ggbTWgcVGkFV8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id :references:to; s=smtpout; bh=EwEwxBdsmLIhg/Ik8QlDPdujXss=; b=mi Z/XxCZ3azaI6jgUCVKxnGpo22SldzI9RDcpTvyRWv/R9hNJJK8HhMqEhXUYYu6iu N4DwJYEQsrhIX7wJHlCBnomLDciW3BnZFaCr5IxWhx/dFfAqLET+SImp9gy9GSKt pCaIzRo6kWy0EmUbi7uP2YxIIiRTAdn9WNpa2oFIo= X-Sasl-enc: RtTn9ZdVjV6vf8NbUJVJs5iaQNslk6kDsuQHpHjk3Hvc 1376490485 Received: from [172.30.42.15] (unknown [188.221.232.223]) by mail.messagingengine.com (Postfix) with ESMTPA id 5497EC00E80 for ; Wed, 14 Aug 2013 10:28:05 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Fred Stratton In-Reply-To: Date: Wed, 14 Aug 2013 15:28:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CA86B40-F485-4164-B183-E0A53D800FC8@imap.cc> <1B9D935F-E68A-490A-992A-6D219E1FB9D4@imap.cc> <32AAB67F-48B4-4504-8772-CF4229CB11B8@imap.cc> To: "cerowrt-devel@lists.bufferbloat.net" X-Mailer: Apple Mail (2.1508) Subject: Re: [Cerowrt-devel] AQM and ADSL 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: Wed, 14 Aug 2013 14:28:07 -0000 On 14 Aug 2013, at 15:18, Sebastian Moeller wrote: > Hi Fred, >=20 >=20 > On Aug 14, 2013, at 15:37 , Fred Stratton = wrote: >=20 >>=20 >> On 14 Aug 2013, at 14:31, Sebastian Moeller wrote: >>=20 >>> Hi Fred, >>>=20 >>>=20 >>> On Aug 14, 2013, at 14:01 , Fred Stratton = wrote: >>>=20 >>>>=20 >>>> On 14 Aug 2013, at 12:42, Sebastian Moeller = wrote: >>>>=20 >>>>> Hi Fred, >>>>>=20 >>>>>=20 >>>>> On Aug 13, 2013, at 21:40 , Fred Stratton = wrote: >>>>>=20 >>>>>> (apologies for wrecking the list, and introducing email addresses = in error) >>>>>>=20 >>>>>>=20 >>>>>> Begin forwarded message >>>>>>> On 13 Aug 2013, at 19:53, Sebastian Moeller = wrote: >>>>>>>=20 >>>>>>>> H Fred >>>>>>>> On Aug 13, 2013, at 17:28 , Fred Stratton = wrote: >>>>>>>>=20 >>>>>>>>> I have been experimenting with the two sets of modified sets = of scripts and AQM panels. Thank you for constructing them. >>>>>>>>=20 >>>>>>>> Thanks for testing... >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> To mention the string ''for ATM choose' is repeated = erroneously in the extended panel. >>>>>>>>=20 >>>>>>>> Fixed=85 I will try to test whether it actually works = before sending the next version... >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The scripts work. >>>>>>>>>=20 >>>>>>>>> The link layer giving best results is ethernet. >>>>>>>>=20 >>>>>>>> What and how did you measure? Using "use HTB's private = mechanism for linklayer and overhead" or "Use tc's stab mechanism for = linklayer and overhead"? A little browsing of the kernel source makes me = believe that the HTB version is fully busted and will not do anything at = all (so I would have imagined adel atm and ethernet to behave the same). = I am thinking about how to test whether a link layer adjustment works or = not. >>>>>>>=20 >>>>>>> Ein Fehler. I had both chosen. They are mutually exclusive = options. 2 days of testing lost. Shall restart. >>>>>=20 >>>>> I will try to fix the AQM scripts to make these two mutually = exclusive. That said, the HTB internal implementation does not seem to = work at all, so enabling both should be equivalent to just enabling = stab. In my quick and dirty testing (using netsurf-wrapper, which I got = working on macosx 10.8) it looks like activating both actually should = work. BTW I am looking for an open netsurf server in Europe anybody any = ideas? >>>>=20 >>>> I am actually getting better results from htb than td-stab at = present. >>>=20 >>> Then I will have to test an compare the RRUL performance for = stab-linklayeradjustments (loa), htb-lla, no-lla, no-shaping at all, at = 50% of link rate and at say 80% of link rate and see which performs = best. Alas I need a closer netperf 2.6.0 net server binary than the ones = in NY and CA. So far I am failing to find a windows binary I could run = on one of the machines in the lab=85 >>> How do you measure currently? I would love to run the same tests = to figure out what is up with the two loa methods. >>=20 >> Netalyzr, for all its deficiencies. >=20 > Ah, so you are basically testing the maximum depth of the ge00 = uplink fq_codels, which is set at 600 at the moment. You could test this = by changing the value in egress() if simple.qos >=20 > $TC qdisc add dev $IFACE parent 1:11 handle 110: $QDISC limit 600 = $NOECN `get_quantum 300` `get_flows ${PRIO_RATE}` > $TC qdisc add dev $IFACE parent 1:12 handle 120: $QDISC limit 600 = $NOECN `get_quantum 300` `get_flows ${BE_RATE}` > $TC qdisc add dev $IFACE parent 1:13 handle 130: $QDISC limit 600 = $NOECN `get_quantum 300` `get_flows ${BK_RATE}` >=20 > to=20 >=20 > $TC qdisc add dev $IFACE parent 1:11 handle 110: $QDISC limit 300 = $NOECN `get_quantum 300` `get_flows ${PRIO_RATE}` > $TC qdisc add dev $IFACE parent 1:12 handle 120: $QDISC limit 300 = $NOECN `get_quantum 300` `get_flows ${BE_RATE}` > $TC qdisc add dev $IFACE parent 1:13 handle 130: $QDISC limit 300 = $NOECN `get_quantum 300` `get_flows ${BK_RATE}` >=20 > and the reported buffering will get lower=85 I assume that netalyzr = only complains about the uplink and the downlink is okay? Setting limit = higher will make netalyzr more unhappy (up to a certain number over = which netalyzr will get happy again). I assume netalyzr simply uses an = inelastic UDP load of a fixed bandwidth tries to fill buffers until = dropping occurs and deduces the size of the buffer from the amount of = data that passed before dropping, if all fits into the buffer nothing = needs dropping and hence netalyzr should be happy even though the = buffers just got more bloated.=20 >=20 > You could also try http://loki10.mpi-sws.mpg.de/bb/bb.php for = that kind of a test which IIRC uses higher bandwidth probes. >=20 >=20 > But we have been there in the past, see = https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-August/000418.h= tml the critical test is to see whether a concurrent ping or ssh session = stays responsive in spite of the netalyzr probe=85 And interestingly in = the old e-mail cited, no AQM defaulted to 500ms uplink delay, the cable = modems buffer was simply not enormously oversized to begin with=85=20 >=20 > Could you share the netalyzr numbers for no AQM, AQM with HTB = and AQM with stab, in any way? And in case you can run this how do the = ping statistics (example: >=20 > --- www.heise.de ping statistics --- > 10 packets transmitted, 10 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 5.813/6.120/6.619/0.213 ms >=20 > of a concurrent "ping -c 1000 IPADDRESS.OF.NEAREST>ISPHOST" look, = especially the max and stddev values could be interesting=85 There will be a delay. have installed netsurf-wrapper etc, but am having difficulty with the = switches. >=20 >=20 >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Pinging severs whilst running Netalyzr has no effect. >>>>>>>>=20 >>>>>>>> Not being a native english speaker cloud you be more = explicit, please. Was the ping RTT affected by the concurrent netalyzr = run (especially up- and download testing)? Did you get netsurf-wrapper = to work on ubuntu?=20 >>>>>>>=20 >>>>>>> You did not understand because I explained what I did, and I did = the wrong thing. >>>>>>>=20 >>>>>>> Not done properly. Will retry. Netsurf-wrapper will not compile. = I am going to move to a more recent version of Ubuntu. >>>>>=20 >>>>> Interesting, I managed to install it under 64bit Ubuntu 12.04 in = a virtual machine, using the packages Toke supplied. I just added = http://archive.tohojo.dk/ to "Software Sources" in "Update Manager" than = I could use the "Synaptic Package Manager" to install netperf and = netperf-wrapper from Toke's repository; so I guess no ned to compile = anything. (Under maces however installing netsurf-wrapper was slightly = more involved as the recommended way via pip did not work, so I had to = download the netperf-wrapper repository from = https://github.com/tohojo/netperf-wrapper and the cd into the downloaded = directory and issue "sudo python2.7 ./setup.py install" there and I had = to symplink python2.7 to python2, but after that it also worked). >>>>> Just as a illustration what to expect, please find attached the = RRUL results with stab based AQM und without any AQM; clearly fq_codel = improves the ping RTTs a lot, so AQM works. Alas, I did not repeat this = test with shaping enabled but no link layer adjustments or with the HTB = link layer adjustments, so can not really tell, whether RRUL is = sensitive enough to show the effects of link layer adjustments or not = (my bet is on not as RRUL in my understanding uses large packets while = the ATM quantization effects are strongest for small packets). I might = try to do this tonight or when I get around to do it=85 >>>>> I would be really curious to see such plots from your setup for = comparison. >>>>=20 >>>> Will try your suggestion for Ubuntu. >>>>=20 >>>>=20 >>>>>=20 >>>>> >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The tone buckets of the phone signal are translated into ATM = packets by the DSP in the 2 Wire 2700. I have no idea what this closed = source BSD implementation does to the packets before they are sent to = CeroWRT. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am using 3.10.2-1, as I cannot get the latest version to = install with sys upgrade. >>>>>>>=20 >>>>>>> I was trying 3.10.5-1=20 >>>>>=20 >>>>> Ah, good, I might try 3.10.6-1 then directly in tftp mode. Does = anyone know how much time I have between releasing the reset button and = starting the tftp transfer?=20 >>>>>=20 >>>> sys upgrade does not work with the latest build. If you have to = press the recovery button during restart, I cannot se tftp. Does anyone = know of programmatic alternatives? >>>=20 >>> Ah, then is is going to be TFTP I guess. What do you mean by "If = you have to press the recovery button during restart, I cannot se tftp"? = Does the "reboot-with-reset-button-pressed" not work after a failed sys = upgrade? >>=20 >> I cannot press the reset button whilst restart in the router. The = procedure works, but I cannot do it. >=20 > Ah, good, then I will risk an upgrade. While needing a stool or = ladder I should be able to actually press the button during restart=85 The procedure SHOULD work. I have not tested it. >=20 >> I am looking for an alternative. There will be a programmatic = approach to enter kernel mode. >=20 > Best Regards > Sebastian >=20 >=20 >>>=20 >>> Best Regards >>> Sebastian >>>=20 >>>=20 >>>>> Best >>>>> Sebastian >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> DT has taken to stealth with his releases. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> So 3.10.6-1 fails with sysupgrade? >>>>>>>>=20 >>>>>>>> best >>>>>>>> Sebastian >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Cerowrt-devel mailing list >>>>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >>=20 >=20