Hi Fred,
On Aug 14, 2013, at 16:28 , Fred Stratton <[email protected]> wrote: > > On 14 Aug 2013, at 15:18, Sebastian Moeller <[email protected]> wrote: > >> Hi Fred, >> >> >> On Aug 14, 2013, at 15:37 , Fred Stratton <[email protected]> wrote: >> >>> >>> On 14 Aug 2013, at 14:31, Sebastian Moeller <[email protected]> wrote: >>> >>>> Hi Fred, >>>> >>>> >>>> On Aug 14, 2013, at 14:01 , Fred Stratton <[email protected]> wrote: >>>> >>>>> >>>>> On 14 Aug 2013, at 12:42, Sebastian Moeller <[email protected]> wrote: >>>>> >>>>>> Hi Fred, >>>>>> >>>>>> >>>>>> On Aug 13, 2013, at 21:40 , Fred Stratton <[email protected]> wrote: >>>>>> >>>>>>> (apologies for wrecking the list, and introducing email addresses in >>>>>>> error) >>>>>>> >>>>>>> >>>>>>> Begin forwarded message >>>>>>>> On 13 Aug 2013, at 19:53, Sebastian Moeller <[email protected]> wrote: >>>>>>>> >>>>>>>>> H Fred >>>>>>>>> On Aug 13, 2013, at 17:28 , Fred Stratton <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I have been experimenting with the two sets of modified sets of >>>>>>>>>> scripts and AQM panels. Thank you for constructing them. >>>>>>>>> >>>>>>>>> Thanks for testing... >>>>>>>>> >>>>>>>>>> >>>>>>>>>> To mention the string ''for ATM choose' is repeated erroneously in >>>>>>>>>> the extended panel. >>>>>>>>> >>>>>>>>> Fixed… I will try to test whether it actually works before >>>>>>>>> sending the next version... >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The scripts work. >>>>>>>>>> >>>>>>>>>> The link layer giving best results is ethernet. >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>>>>> Ein Fehler. I had both chosen. They are mutually exclusive options. 2 >>>>>>>> days of testing lost. Shall restart. >>>>>> >>>>>> 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? >>>>> >>>>> I am actually getting better results from htb than td-stab at present. >>>> >>>> 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… >>>> How do you measure currently? I would love to run the same tests to >>>> figure out what is up with the two loa methods. >>> >>> Netalyzr, for all its deficiencies. >> >> 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 >> >> $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}` >> >> to >> >> $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}` >> >> and the reported buffering will get lower… 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. >> >> 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. >> >> >> But we have been there in the past, see >> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-August/000418.html >> the critical test is to see whether a concurrent ping or ssh session stays >> responsive in spite of the netalyzr probe… 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… >> >> 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: >> >> --- www.heise.de ping statistics --- >> 10 packets transmitted, 10 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 5.813/6.120/6.619/0.213 ms >> >> of a concurrent "ping -c 1000 IPADDRESS.OF.NEAREST>ISPHOST" look, especially >> the max and stddev values could be interesting… > > 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. > > have installed netsurf-wrapper etc, but am having difficulty with the > switches. Ah, so I so far simply used ./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). I hope this gets you going… Best Sebastian > > >> >> >>>> >>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Pinging severs whilst running Netalyzr has no effect. >>>>>>>>> >>>>>>>>> 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? >>>>>>>> >>>>>>>> You did not understand because I explained what I did, and I did the >>>>>>>> wrong thing. >>>>>>>> >>>>>>>> Not done properly. Will retry. Netsurf-wrapper will not compile. I am >>>>>>>> going to move to a more recent version of Ubuntu. >>>>>> >>>>>> 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… >>>>>> I would be really curious to see such plots from your setup for >>>>>> comparison. >>>>> >>>>> Will try your suggestion for Ubuntu. >>>>> >>>>> >>>>>> >>>>>> <figure_5.png><figure_6_like_5_noAQM.png> >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am using 3.10.2-1, as I cannot get the latest version to install >>>>>>>>>> with sys upgrade. >>>>>>>> >>>>>>>> I was trying 3.10.5-1 >>>>>> >>>>>> 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? >>>>>> >>>>> 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? >>>> >>>> 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? >>> >>> I cannot press the reset button whilst restart in the router. The >>> procedure works, but I cannot do it. >> >> 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… > > The procedure SHOULD work. I have not tested it. >> >>> I am looking for an alternative. There will be a programmatic approach to >>> enter kernel mode. >> >> Best Regards >> Sebastian >> >> >>>> >>>> Best Regards >>>> Sebastian >>>> >>>> >>>>>> Best >>>>>> Sebastian >>>>>> >>>>>> >>>>>>>> >>>>>>>> DT has taken to stealth with his releases. >>>>>>>> >>>>>>>>> >>>>>>>>> So 3.10.6-1 fails with sysupgrade? >>>>>>>>> >>>>>>>>> best >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Cerowrt-devel mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Cerowrt-devel mailing list >>>>>>> [email protected] >>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Cerowrt-devel mailing list >>>>> [email protected] >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>> >>> >> > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
