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. have installed netsurf-wrapper etc, but am having difficulty with the switches. > > >>> >>> >>>>> >>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 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
