From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AF44921F1A4 for ; Sun, 25 Aug 2013 13:28:12 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so2061300wgh.2 for ; Sun, 25 Aug 2013 13:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bdOGaUt6pqz/OE7Iz0FTpE6iAqOkVH14Hkd+AF1gpBw=; b=G0B8HQJPZqE+XZRnkg+p//Sdz8XxpzP506dxb0kw5lP4SmGvA2OmZI0XLZg+yUf2h2 rqL0+gTwwp5Uz9cKT2GoKt3Zgx6RZnXq6dFrTr8QmGlTmXuxWD37xqVPbgNZ6imB5R7C ah7jEhqgmcnEFboulfQrw+gu9n50K2NG+U/SsPLfEadpiANgvgqvidNbLs/SlKLCi9Fb ykoTvDoiW0Dv8auDg8Zc2PT31bM8X/IbvAt3+OcGfw+vSpK9u7BjsHwCxLAZayTS/BcS wKD4jiFntNDNcdfXNkQWzJh3R0cVeYrQ7moQQI3VqVGH4HFb4DADpbjd3bPayo8KrjPr 0V9A== MIME-Version: 1.0 X-Received: by 10.180.84.196 with SMTP id b4mr5263921wiz.19.1377462490499; Sun, 25 Aug 2013 13:28:10 -0700 (PDT) Received: by 10.217.48.67 with HTTP; Sun, 25 Aug 2013 13:28:10 -0700 (PDT) In-Reply-To: References: <56B261F1-2277-457C-9A38-FAB89818288F@gmx.de> <2148E2EF-A119-4499-BAC1-7E647C53F077@gmx.de> <03951E31-8F11-4FB8-9558-29EAAE3DAE4D@gmx.de> <9A9B094D-CA07-48B0-85FE-FA7C759FEDE3@gmx.de> <5BEF0C7C-C2F4-45A9-9FF2-E32A05B8D67B@gmx.de> <8CD72282-88CB-43FD-84EF-574DDB23F0AB@gmx.de> <0886582B-E46C-4F93-A9E5-C45A81C32AEA@imap.cc> <8AFDEBD8-54C9-46B6-8CBE-5CD4242A2765@imap.cc> Date: Sun, 25 Aug 2013 13:28:10 -0700 Message-ID: From: Dave Taht To: Fred Stratton Content-Type: multipart/alternative; boundary=f46d04426e2a700e5704e4cb7a66 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] some kernel updates 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: Sun, 25 Aug 2013 20:28:14 -0000 --f46d04426e2a700e5704e4cb7a66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The rule of thumb for fixing downloads is to start at 85% of your rated dl and try to get to 95%. It is unfortunately very subject to the RTT of your last hop, which on DSL is quite a lot, so I would be surprised if you could crack 90%. Cutting it by 50% is a bit much tho! (It would, as always, be best if the provider used something fq_codel like on their rate limiter, not yours). but I'm glad to hear you are making progress! On Sun, Aug 25, 2013 at 12:08 PM, Fred Stratton wrote= : > That is very helpful. > > With a sync rate of about 12000 kbits/s, and a download rate of about > 10900 kbits/s. I have set the download rate to 5000 kbits/s. For upload > similarly 1200/970/500, all kbits/s. > > I can now mostly watch video in iPlayer and download at circa 300 - 400 > kbits/s simultaneously, using htb, with tc-stab disabled. > > QED > > > On 25 Aug 2013, at 19:41, Dave Taht wrote: > > So it sounds like you need a lower setting for the download than what you > are using? It's not the upload that is your problem. > > Netanalyzer sends one packet stream and thus measures 1 queue only. > fq_codel will happily give it one big queue for a while, while still > interleaving other flows's packets into the stream at every opportunity. > > as for parsing rrul I generally draw a line with my hand and multiply by > 4, then fudge in the numbers for the reverse ack and measurement streams. > > > You are saying that you judge the result solely by eye. presumably. > > > As written it was targetted at 4Mbit and up which is why the samples are > discontinuous in your much lower bandwidth situation. > > > Aha. Problem solved. > > > I do agree that rrul could use a simpler implementation, perhaps one that > tested two download streams only, and provided an estimate as to the actu= al > bandwidth usage, and scale below 4Mbit better. > > > On Sun, Aug 25, 2013 at 11:30 AM, Fred Stratton wro= te: > >> >> On 25 Aug 2013, at 18:53, Sebastian Moeller wrote: >> >> > Hi Fred, >> > >> > >> > On Aug 25, 2013, at 16:26 , Fred Stratton 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 i= f >> 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 al= low >> to select both. Since I have not tested it any other way I would recomme= nd >> 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, be= st >> 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=85 >> >> I have retained the unmodified script. I shall return to that. >> >> >> > >> >> On 25 Aug 2013, at 14:59, Sebastian Moeller wrote: >> >> >> >>> Hi Fred, >> >>> >> >>> >> >>> On Aug 25, 2013, at 12:17 , Fred Stratton >> wrote: >> >>> >> >>>> >> >>>> On 25 Aug 2013, at 10:21, Fred Stratton >> 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 H= EC, >> 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, sa= y, >> 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 o= r >> not. (You could test this by shaping you up and downlink to <=3D 50% of = the >> link rates and disable all link layer adjustments, 50% is larger than th= e >> 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.atlo= wer snr. " so sync at 12162 might be too aggressive, no? But the point is >> that as I understand iPlayer works fine without competing download traff= ic? >> To my eye the error numbers look small enough to not be concerned about.= Do >> you know how long the error correction period is? >> >> The correction period is probably circa 28 hours. Have moved to using th= e >> HG612. This is uses the Broadcom 6368 SoC. Like most of the devices I us= e, >> it fell out of a BT van and on to ebay. It is the standard device used f= or >> connecting FTTC installations in the UK. With a simple modification, it >> will work stably with ADSL2+. >> >> Ihe sync rate has gone up considerably, not because I have changed the >> Target SNR from 12 Decibel, but because I am now using a Broadcom chipse= t >> and software blob with a DSLAM which returns BDCM when interrogated. >> > >> > >> >> >> >>> Could you perform the following test by any chance: state iPlaye= r >> 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 strea= m >> 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 workin= g >> or just gets choppier? Looking at your sync data 561 would fit the ~50% = and >> above 500 requirements. >> >> I was basing the judgment on Netalyzr data. DT and you now say this is >> suspect. However, netsurf-wrapper traces are discontinuous. The actual r= eal >> time trace looks perfectly normal. >> >> iPlayer is a Flash based player which is web page embedded. The ipv4 >> user address is parsed to see if it is in the UK. It plays BBC TV progra= ms. >> It most likely is badly designed and written. It is the way I watch TV. >> Like all UK residents, I pay the bloated bureaucracy of the BBC a yearly >> fee of about 200 euro. If I do not pay, I will be fined. You will be >> surprised that I am not a fan of the BBC. iPlayer starts and runs fine, = but >> if a download is commenced whilst it is running, so I can watch the >> propaganda put out as national news, the video will stall and the contin= ue, >> but most commonly will stop. >> > >> > >> >>> >> >>> >> >>>>> >> >>>>> 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 A= QM >> 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 wil= l >> 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=3DADSL2 >> >>> # 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=3D87.186.197.70 # T >> >>> DATESTR=3D`date +%Y%m%d_%H%M%S` # to allow multiple sequential >> records >> >>> LOG=3Dping_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=3D0.01 # in seconds >> >>> PINGSPERSIZE=3D10000 >> >>> >> >>> # 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=3D16 # 64bit systems seem to require 16 byt= es >> of payload to include a timestamp... >> >>> SWEEPMAXSIZE=3D116 >> >>> >> >>> >> >>> n_SWEEPS=3D`expr ${SWEEPMAXSIZE} - ${SWEEPMINSIZE}` >> >>> >> >>> >> >>> i_sweep=3D0 >> >>> i_size=3D0 >> >>> >> >>> while [ ${i_sweep} -lt ${PINGSPERSIZE} ] >> >>> do >> >>> (( i_sweep++ )) >> >>> echo "Current iteration: ${i_sweep}" >> >>> # now loop from sweepmin to sweepmax >> >>> i_size=3D${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 slee= p >> 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 lin= k >> 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 mig= ht >> 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. >> >> How do you obtain an average i.e. mean rate from the RRUL graph? >> > >> > >> >> >> >>> >> >>>>> >> >>>>> 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= =85 >> >>>>> >> >>>>> 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 an= d >> fq_codel on simplest.qos, how does that reconcile with 650ms uplink dela= y, >> 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 f= or >> UDP floods :) ) >> > >> > [snipp] >> > >> > >> > Best Regards >> > Sebastian >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --f46d04426e2a700e5704e4cb7a66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The rule of thumb for fixing downloads is to start at 85% = of your rated dl and try to get to 95%. It is unfortunately very subject to= the RTT of your last hop, which on DSL is quite a lot, so I would be surpr= ised if you could crack 90%.=A0 Cutting it by 50% is a bit much tho! (It wo= uld, as always, be best if the provider used something fq_codel like on the= ir rate limiter, not yours).

but I'm glad to hear you are making progress!


On Sun, Aug 25, 2013 at= 12:08 PM, Fred Stratton <fredstratton@imap.cc> wrote:
That is = very helpful.

With a sync rate of about 12000 kbits/s, a= nd a download rate of about 10900 kbits/s. I have set the download rate to = 5000 kbits/s. For upload similarly 1200/970/500, all kbits/s.

I can now mostly watch video in iPlayer and download at= circa 300 - 400 kbits/s simultaneously, using htb, with tc-stab disabled.<= /div>

QED


On 25 Aug 2013, at 19:41, Dave Taht <dave.taht@gmail.com> wrote:

So it sounds like you= need a lower setting for the download than what you are using? It's no= t the upload that is your problem.

Netanalyzer sends one packet stream and thus measures 1 queue onl= y. fq_codel will happily give it one big queue for a while, while still int= erleaving other flows's packets into the stream at every opportunity. <= br>
as for parsing rrul I generally draw a line with my hand and mult= iply by 4, then fudge in the numbers for the reverse ack and measurement st= reams.

You are saying tha= t you judge the result solely by eye. presumably.


As written it was t= argetted at 4Mbit and up which is why the samples are discontinuous in your= much lower bandwidth situation.

Aha. Problem solved.


I do agree that rrul could use a simpler implementation, perhaps = one that tested two download streams only, and provided an estimate as to t= he actual bandwidth usage, and scale below 4Mbit better.


On Sun, Aug 25, 2013 at 11:30 AM, Fred S= tratton <fredstratton@imap.cc> wrote:

On 25 Aug 2013, at 18:53, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Fred,
>
>
> On Aug 25, 2013, at 16:26 , Fred Stratton <fredstratton@imap.cc> w= rote:
>
>> 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.
>
> =A0 =A0 =A0 I have seen your follow-up mail that you actually us= ed 3.10.9-2. I think that has the first cut of the script modifications tha= t still allow to select both. Since I have not tested it any other way I wo= uld recommend to enable just one of them at the same time. Since the implem= entation 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) an= d the overhead applied twice, wasting bandwidth. So please either use the l= ast set of modified files I send around or wait for Dave to include them in= ceropackages=85

I have retained the unmodified script. I shall return to that.


>
>> On 25 Aug 2013, at 14:59, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>> Hi Fred,
>>>
>>>
>>> On Aug 25, 2013, at 12:17 , Fred Stratton <fredstratton@imap.cc> wrot= e:
>>>
>>>>
>>>> On 25 Aug 2013, at 10:21, Fred Stratton <fredstratton@imap.cc> wr= ote:
>>>>
>>>>> As the person with the most flaky ADSL link, I point o= ut that None of these recent, welcome, changes, are having any effect here,= with an uplink sped of circa 950 kbits/s.
>>>
>>> =A0 =A0 Okay, how flaky is you link? What rate of Errors do yo= u have while testing? I am especially interested in CRC errors and ES SES a= nd HEC, just to get an idea how flaky the line is...
>>>
>>>>>
>>>>> The reason I mention this is that it is still impossib= le to watch iPlayer Flash streaming video and download at the same time, Th= e iPlayer stream fails. The point of the exercise was to achieve this.
>>>>>
>>>>> The uplink delay is consistently around 650ms, which a= ppears to be too high for effective streaming. In addition, the uplink stre= am has multiple breaks, presumably outages, if the uplink rate is capped at= , say, 700 kbits/s.
>>>
>>> =A0 =A0 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 downl= ink errors as far as I can tell from the data you have given. If the up lin= k has repeated outages however, your problems might be unfixable because th= ese, if long enough, will cause lost ACKs and will probably trigger retrans= mission, independent of whether the link layer adjustments work or not. (Yo= u could test this by shaping you up and downlink to <=3D 50% of the link= rates and disable all link layer adjustments, 50% is larger than the ATM w= orst case so should have you covered. Well unless you del link has an exces= sive 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.
>
> =A0 =A0 =A0 Ah, I think you told me in the past that "Target snr = upped to 12 deciBel. =A0Line can sustain 10 megabits/s with repeated loss o= f sync.at lower snr. &quo= t; 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 ey= e the error numbers look small enough to not be concerned about. Do you kno= w how long the error correction period is?

The correction period is probably circa 28 hours. Have moved to using= the HG612. This is uses the Broadcom 6368 SoC. Like most of the devices I = use, it fell out of a BT van and on to ebay. It is the standard device used= for connecting FTTC installations in the UK. With a simple modification, i= t will work stably with ADSL2+.

Ihe sync rate has gone up considerably, not because I have changed the Targ= et SNR from 12 Decibel, but because I am now using a Broadcom chipset and s= oftware blob with a DSLAM which returns BDCM when interrogated.
>
>
>>
>>> =A0 =A0 Could you perform the following test by any chance: st= ate iPlayer and yor typical downloads and then have a look at http://gw.home.lan:81und the = following tab chain Status -> Realtime Graphs -> Traffic -> Realti= me Traffic. If during your test the Outbound rate stays well below you shap= ed 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 t= o have difficulty operating below circa 500 kbits/s. This should not be so.= I shall try a fourth time.
>
> =A0 =A0 =A0 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.

I was basing the judgment on Netalyzr data. DT and you now say this i= s suspect. However, netsurf-wrapper traces are discontinuous. The actual re= al time trace looks perfectly normal.

iPlayer is a Flash based player which is web page embedded. =A0The ipv4 use= r address is parsed to see if it is in the UK. It plays BBC TV programs. It= most likely is badly designed and written. It is the way I watch TV. Like = all UK residents, I pay the bloated bureaucracy of the BBC a yearly fee of = about 200 euro. If I do not pay, I will be fined. You will be surprised tha= t I am not a fan of the BBC. iPlayer starts and runs fine, but if a downloa= d is commenced whilst it is running, so I can watch the propaganda put out = as national news, the video will stall and the continue, but most commonly = will stop.
>
>
>>>
>>>
>>>>>
>>>>> YouTube has no problems.
>>>>>
>>>>> I remain unclear whether the use of tc-stab and htb ar= e mutually exclusive options, using the present stock interface.
>>>
>>> =A0 =A0 Well, depending on the version of the cerowrt you use,= <3.10.9-1 I believe lacks a functional HTB link layer adjustment mechan= ism, 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 la= yer adjustments) LLA twice
>>
>>
>>> See initial comments.
>>>
>>>>>
>>>>> The current ISP connection is IPoA LLC.
>>>>
>>>> Correction - Bridged LLC.
>>>
>>> =A0 =A0 Well, I think you should try to figure out your overhe= ad empirically and check the encapsulation. I would recommend you run the f= ollowing script on you r link over night and send me the log file it produc= es:
>>>
>>> #! /bin/bash
>>> # TODO use seq or bash to generate a list of the requested siz= es (to alow for non-equdistantly spaced sizes)
>>>
>>> # Telekom Tuebingen Moltkestrasse 6
>>> TECH=3DADSL2
>>> # finding a proper target IP is somewhat of an art, just trace= route a remote site
>>> # and find the nearest host reliably responding to pings showi= ng the smallet variation of pingtimes
>>> TARGET=3D87.186.197.70 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# T
>>> DATESTR=3D`date +%Y%m%d_%H%M%S` =A0 =A0 =A0 # to allow multipl= e sequential records
>>> LOG=3Dping_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=3D0.01 =A0 =A0 =A0 =A0 =A0 =A0 # in seconds
>>> PINGSPERSIZE=3D10000
>>>
>>> # Start, needed to find the per packet overhead dependent on t= he ATM encapsulation
>>> # to reliably show ATM quantization one would like to see at l= east two steps, so cover a range > 2 ATM cells (so > 96 bytes)
>>> SWEEPMINSIZE=3D16 =A0 =A0 =A0 =A0 =A0 =A0 # 64bit systems seem= to require 16 bytes of payload to include a timestamp...
>>> SWEEPMAXSIZE=3D116
>>>
>>>
>>> n_SWEEPS=3D`expr ${SWEEPMAXSIZE} - ${SWEEPMINSIZE}`
>>>
>>>
>>> i_sweep=3D0
>>> i_size=3D0
>>>
>>> while [ ${i_sweep} -lt ${PINGSPERSIZE} ]
>>> do
>>> =A0 (( i_sweep++ ))
>>> =A0 echo "Current iteration: ${i_sweep}"
>>> =A0 # now loop from sweepmin to sweepmax
>>> =A0 i_size=3D${SWEEPMINSIZE}
>>> =A0 while [ ${i_size} -le ${SWEEPMAXSIZE} ]
>>> =A0 do
>>> =A0 =A0 echo "${i_sweep}. repetition of ping size ${i_siz= e}"
>>> =A0 =A0 ping -c 1 -s ${i_size} ${TARGET} >> ${LOG} &=
>>> =A0 =A0 (( i_size++ ))
>>> =A0 =A0 # we need a sleep binary that allows non integer times= (GNU sleep is fine as is sleep of macosx 10.8.4)
>>> =A0 =A0 sleep ${PINGPERIOD}
>>> =A0 done
>>> done
>>>
>>> #tail -f ${LOG}
>>>
>>> echo "Done... ($0)"
>>>
>>>
>>> Please set TARGET to the closest IP host on the ISP side of yo= ur link that gives reliable ping RTTs (using "ping -c 100 -s 16 your.b= est.host.ip"). Also test whether the RTTs are in the same ballpark whe= n 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 th= en run this through my matlab code to detect the actual overhead. (I am hap= py to share the code as well, if you have matlab available; it might even r= un under octave but I have not tested that since the last major changes). >>
>> To follow at some point.
>
> =A0 =A0 =A0 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 chang= e.
>>>
>>> =A0 =A0 I assume you talk about the overhead? Missing link lay= er adjustment will eat between 50% and 10% of your link bandwidth, while mi= ssing 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 purpos= es. I shall move to PPPoA VC-MUX in 4 months.
>
> =A0 =A0 =A0 I guess figuring out you exact overhead empirically is goi= ng to be fun.
>
>>>
>>>>>
>>>>> I have applied the ingress modification to simple.qos,= keeping the original version., and tested both.
>>>
>>> =A0 =A0 For which cerowrt version? It is only expected to do s= omething for 3.10.9-1 and upwards, before that the HTB lionklayer adjustmen= t did NOT work.
>>
>> Using 3.10.9-2
>
> =A0 =A0 =A0 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 cond= itions. I would estimate the most interesting part would be in the sustaine= d ravager up and download rates here.

How do you obtain an average i.e. mean rate from the RRUL graph= ?
>
>
>>
>>>
>>>>>
>>>>> I have changed the Powerline adaptors I use to ones wi= th 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, wit= h a simple password, which cannot be changed other than by firmware recompi= lation=85
>>>>>
>>>>> Telnet, however, allows txqueuelen to be reduced from = 1000 to 0.
>>>>>
>>>>> None of these changes affect the problematic uplink de= lay.
>>>
>>> =A0 =A0 So how did you measure the uplink delay? The RRUL plot= s 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 upli= nk delay, netalyzr?
>>
>> Max Planck and Netalyzr produce the same figure. I use both, but M= ax Planck gives you circa 3 tries per IP address per 24 hours.
>
> =A0 =A0 =A0 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 syst= em for UDP floods :) )
>
> [snipp]
>
>
> Best Regards
> =A0 =A0 =A0 Sebastian

_______________________________________________
Cerowrt-devel mailing list
Ce= rowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel



--
Dave T=E4ht=

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/= subscribe.html=20


________________________= _______________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel




--
Dave T=E4ht

= Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html=20 --f46d04426e2a700e5704e4cb7a66--