From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4AEFB21F1C4 for ; Wed, 14 Aug 2013 08:09:31 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lp3Lw-1VoA3E3sWK-00exmV for ; Wed, 14 Aug 2013 17:09:24 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 14 Aug 2013 17:09:23 +0200 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: Fred Stratton X-Mailer: Apple Mail (2.1508) X-Provags-ID: V03:K0:B4tW+Lm2C7J9R+9/cn9XlMPu2YcwlVWMhf0PMX04P6NzgK/Q+oE sg1OmfzqwDZjco2xg0ibuY9jaGq95Eb/4X5GmJ+chmNxrFgwjyd+ekpQhxaVspEcw73AYb7 ga/kwWy5fxAyUcFrG5tEX1nvgHvlPM8XE2ONElza2aLCneGKmNGj9Nd2OgVeB225yguV90H Ispwu8HKzIinmos88ETdw== Cc: "cerowrt-devel@lists.bufferbloat.net" 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 15:09:33 -0000 Hi Fred, On Aug 14, 2013, at 16:28 , Fred Stratton wrote: >=20 > On 14 Aug 2013, at 15:18, Sebastian Moeller wrote: >=20 >> 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 >=20 > There will be a delay. I do not think that these measurements will be too revealing = anyways, netalyzr is a good test for simple pfifo or pfifo_fast discs, = but not too interesting for fq_codel. In case you stick to using = netalyzr concurrent ping data might be nice, but better switch to a = different latency probe. >=20 > have installed netsurf-wrapper etc, but am having difficulty with the = switches. Ah, so I so far simply used=20 ./netperf-wrapper -l 60 -H snapon.lab.bufferbloat.net rrul -p all_scaled to at least get pretty pictures for my quick and dirty testing. The -l = NN controls the duration of the test, the -H the host, I found that both = snapon.lab.bufferbloat.net and icei.org seem to be open netsurf servers = (as Dave announced earlier this year), I do not know whether these are = supposed to be used by everyone or not (and it would be nice to have a = net server closer in Europe anyways).=20 I hope this gets you going=85 Best Sebastian >=20 >=20 >>=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 >=20 > 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 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel