On 25 Aug 2013, at 18:55, Dave Taht <[email protected]> wrote: > Netanalyzer is not useful in a fq_codel'ed system.
Thank you. I shall stop using it. > > > On Sun, Aug 25, 2013 at 10:53 AM, Sebastian Moeller <[email protected]> wrote: > Hi Fred, > > > On Aug 25, 2013, at 16:26 , Fred Stratton <[email protected]> wrote: > > > Thank you. > > > > This is an initial response. > > > > Am using 3.10.2-1 currently, with the standard AQM interface. This does not > > have the pull down menu of your interface, which is why I ask if both are > > active. > > I have seen your follow-up mail that you actually used 3.10.9-2. I > think that has the first cut of the script modifications that still allow to > select both. Since I have not tested it any other way I would recommend to > enable just one of them at the same time. Since the implementation of both is > somewhat orthogonal and htb_private actually works in 3.10.9, best case you > might actually get the link layer adjustments (LLA) and the overhead applied > twice, wasting bandwidth. So please either use the last set of modified files > I send around or wait for Dave to include them in ceropackages... > > > On 25 Aug 2013, at 14:59, Sebastian Moeller <[email protected]> wrote: > > > >> Hi Fred, > >> > >> > >> On Aug 25, 2013, at 12:17 , Fred Stratton <[email protected]> wrote: > >> > >>> > >>> On 25 Aug 2013, at 10:21, Fred Stratton <[email protected]> wrote: > >>> > >>>> As the person with the most flaky ADSL link, I point out that None of > >>>> these recent, welcome, changes, are having any effect here, with an > >>>> uplink sped of circa 950 kbits/s. > >> > >> Okay, how flaky is you link? What rate of Errors do you have while > >> testing? I am especially interested in CRC errors and ES SES and HEC, just > >> to get an idea how flaky the line is... > >> > >>>> > >>>> The reason I mention this is that it is still impossible to watch > >>>> iPlayer Flash streaming video and download at the same time, The iPlayer > >>>> stream fails. The point of the exercise was to achieve this. > >>>> > >>>> The uplink delay is consistently around 650ms, which appears to be too > >>>> high for effective streaming. In addition, the uplink stream has > >>>> multiple breaks, presumably outages, if the uplink rate is capped at, > >>>> say, 700 kbits/s. > >> > >> Well, watching video is going to stress your downlink so the uplink > >> should not saturate by the ACKs and the concurrent downloads also do not > >> stress your uplink except for the ACKs, so this points to downlink errors > >> as far as I can tell from the data you have given. If the up link has > >> repeated outages however, your problems might be unfixable because these, > >> if long enough, will cause lost ACKs and will probably trigger > >> retransmission, independent of whether the link layer adjustments work or > >> not. (You could test this by shaping you up and downlink to <= 50% of the > >> link rates and disable all link layer adjustments, 50% is larger than the > >> ATM worst case so should have you covered. Well unless you del link has an > >> excessive number of tones reserved for forward error correction (FEC)). > > > > Uptime 100655 > > downstream 12162 kbits/s > > CRC errors 10154 > > FEC Errors 464 > > hEC Errors 758 > > > > upstream 1122 kbits/s > > no errors in period. > > Ah, I think you told me in the past that "Target snr upped to 12 > deciBel. Line can sustain 10 megabits/s with repeated loss of sync.at lower > snr. " so sync at 12162 might be too aggressive, no? But the point is that as > I understand iPlayer works fine without competing download traffic? To my eye > the error numbers look small enough to not be concerned about. Do you know > how long the error correction period is? > > > > > >> Could you perform the following test by any chance: state iPlayer and > >> yor typical downloads and then have a look at http://gw.home.lan:81und the > >> following tab chain Status -> Realtime Graphs -> Traffic -> Realtime > >> Traffic. If during your test the Outbound rate stays well below you shaped > >> limit and you still encounter the stream failure I would say it is save to > >> ignore the link layer adjustments as cause of your issues. > > > > Am happy reducing rate to fifty per cent, but the uplink appears to have > > difficulty operating below circa 500 kbits/s. This should not be so. I > > shall try a fourth time. > > That sounds weird, if you shape to below 500 upload stops working or > just gets choppier? Looking at your sync data 561 would fit the ~50% and > above 500 requirements. > > > >> > >> > >>>> > >>>> YouTube has no problems. > >>>> > >>>> I remain unclear whether the use of tc-stab and htb are mutually > >>>> exclusive options, using the present stock interface. > >> > >> Well, depending on the version of the cerowrt you use, <3.10.9-1 I > >> believe lacks a functional HTB link layer adjustment mechanism, so you > >> should select tc_stab. My most recent modifications to Toke and Dave's AQM > >> package does only allow you to select one or the other. In any case > >> selecting BOTH is not a reasonable thing to do, because best case it will > >> only apply overhead twice, worst case it would also do the (link layer > >> adjustments) LLA twice > > > > > >> See initial comments. > >> > >>>> > >>>> The current ISP connection is IPoA LLC. > >>> > >>> Correction - Bridged LLC. > >> > >> Well, I think you should try to figure out your overhead empirically > >> and check the encapsulation. I would recommend you run the following > >> script on you r link over night and send me the log file it produces: > >> > >> #! /bin/bash > >> # TODO use seq or bash to generate a list of the requested sizes (to alow > >> for non-equdistantly spaced sizes) > >> > >> # Telekom Tuebingen Moltkestrasse 6 > >> TECH=ADSL2 > >> # finding a proper target IP is somewhat of an art, just traceroute a > >> remote site > >> # and find the nearest host reliably responding to pings showing the > >> smallet variation of pingtimes > >> TARGET=87.186.197.70 # T > >> DATESTR=`date +%Y%m%d_%H%M%S` # to allow multiple sequential records > >> LOG=ping_sweep_${TECH}_${DATESTR}.txt > >> > >> > >> # by default non-root ping will only end one packet per second, so work > >> around that by calling ping independently for each package > >> # empirically figure out the shortest period still giving the standard > >> ping time (to avoid being slow-pathed by our host) > >> PINGPERIOD=0.01 # in seconds > >> PINGSPERSIZE=10000 > >> > >> # Start, needed to find the per packet overhead dependent on the ATM > >> encapsulation > >> # to reliably show ATM quantization one would like to see at least two > >> steps, so cover a range > 2 ATM cells (so > 96 bytes) > >> SWEEPMINSIZE=16 # 64bit systems seem to require 16 bytes of > >> payload to include a timestamp... > >> SWEEPMAXSIZE=116 > >> > >> > >> n_SWEEPS=`expr ${SWEEPMAXSIZE} - ${SWEEPMINSIZE}` > >> > >> > >> i_sweep=0 > >> i_size=0 > >> > >> while [ ${i_sweep} -lt ${PINGSPERSIZE} ] > >> do > >> (( i_sweep++ )) > >> echo "Current iteration: ${i_sweep}" > >> # now loop from sweepmin to sweepmax > >> i_size=${SWEEPMINSIZE} > >> while [ ${i_size} -le ${SWEEPMAXSIZE} ] > >> do > >> echo "${i_sweep}. repetition of ping size ${i_size}" > >> ping -c 1 -s ${i_size} ${TARGET} >> ${LOG} & > >> (( i_size++ )) > >> # we need a sleep binary that allows non integer times (GNU sleep is > >> fine as is sleep of macosx 10.8.4) > >> sleep ${PINGPERIOD} > >> done > >> done > >> > >> #tail -f ${LOG} > >> > >> echo "Done... ($0)" > >> > >> > >> Please set TARGET to the closest IP host on the ISP side of your link that > >> gives reliable ping RTTs (using "ping -c 100 -s 16 your.best.host.ip"). > >> Also test whether the RTTs are in the same ballpark when you reduce the > >> ping period to 0.01 (you might have to increase the period until the RTTs > >> are close to the standard 1 ping per second case). I can then run this > >> through my matlab code to detect the actual overhead. (I am happy to share > >> the code as well, if you have matlab available; it might even run under > >> octave but I have not tested that since the last major changes). > > > > To follow at some point. > > Oh, I failed to mention at the given parameters the script takes > almost 3 hours, during which the link should be otherwise idle... > > >> > >> > >>> > >>>> Whatever byte value is used for tc-stab makes no change. > >> > >> I assume you talk about the overhead? Missing link layer adjustment > >> will eat between 50% and 10% of your link bandwidth, while missing > >> overhead values will be more benign. The only advise I can give is to pick > >> the overhead that actually describes your link. I am willing to help you > >> figure this out. > > > > The link is bridged LLC. Have been using 18 and 32 for test purposes. I > > shall move to PPPoA VC-MUX in 4 months. > > I guess figuring out you exact overhead empirically is going to be > fun. > > >> > >>>> > >>>> I have applied the ingress modification to simple.qos, keeping the > >>>> original version., and tested both. > >> > >> For which cerowrt version? It is only expected to do something for > >> 3.10.9-1 and upwards, before that the HTB lionklayer adjustment did NOT > >> work. > > > > Using 3.10.9-2 > > Yeah as stated above, I would recommend to use either or, not both. > If you took RRUL data you might be able to compare the three conditions. I > would estimate the most interesting part would be in the sustained ravager up > and download rates here. > > > > > >> > >>>> > >>>> I have changed the Powerline adaptors I use to ones with known smaller > >>>> buffers, though this is unlikely to be a ate-limiting step. > >>>> > >>>> I have changed the 2Wire gateway, known to be heavily buffered, with a > >>>> bridged Huawei HG612, with a Broadcom 6368 SoC. > >>>> > >>>> This device has a permanently on telnet interface, with a simple > >>>> password, which cannot be changed other than by firmware recompilation… > >>>> > >>>> Telnet, however, allows txqueuelen to be reduced from 1000 to 0. > >>>> > >>>> None of these changes affect the problematic uplink delay. > >> > >> So how did you measure the uplink delay? The RRUL plots you sent me > >> show an increase in ping RTT from around 50ms to 80ms with tc_stab and > >> fq_codel on simplest.qos, how does that reconcile with 650ms uplink delay, > >> netalyzr? > > > > Max Planck and Netalyzr produce the same figure. I use both, but Max Planck > > gives you circa 3 tries per IP address per 24 hours. > > Well, both use the same method which is not to meaningful if you use > fq_codel on a shaped link (unless you want to optimize your system for UDP > floods :) ) > > [snipp] > > > Best Regards > Sebastian > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
