From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (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 271A721F1A4 for ; Sun, 25 Aug 2013 11:41:23 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t61so2099918wes.0 for ; Sun, 25 Aug 2013 11:41:22 -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=bs/Bxz5cFDAEhIQm9836whRzqlgImDmFlbnsW2/Aiwo=; b=D+7dtnSdcuh8uA7LyPudhmoT9TqTofkxLNQv9vfVtJ0J+bVkCFfPg8P/N6qJdYmXf3 SgqfJIiLCjXWqwH3ek9KIgDMr+52lBZnJ0fg3bLDFKs3bRzhlahGg+7c704QBgIT3enD 7zzMXT632lUAW4b9nd7vJ660Xf1SwBHbMnb7X8MnkZXaMFdjWzF3EUlnpYhgLQMpx9Tq wZsgczStr96W+Njuap4a3YfzhtTLemi73nvEXtc0MZ5yer/2kclMjnbgVnZoPL7ywBaF CxYajd7ZjXOPx1q69C6byztGNaOy6VHzgk8kiy3d0ZlDnHLGNF45hnctCXM4XIQjVeLT U8hw== MIME-Version: 1.0 X-Received: by 10.180.74.134 with SMTP id t6mr4890364wiv.56.1377456080859; Sun, 25 Aug 2013 11:41:20 -0700 (PDT) Received: by 10.217.48.67 with HTTP; Sun, 25 Aug 2013 11:41:20 -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 11:41:20 -0700 Message-ID: From: Dave Taht To: Fred Stratton Content-Type: multipart/alternative; boundary=f46d043c820c64b9d704e4c9fcae 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 18:41:24 -0000 --f46d043c820c64b9d704e4c9fcae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. As written it was targetted at 4Mbit and up which is why the samples are discontinuous in your much lower bandwidth situation. 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 actual bandwidth usage, and scale below 4Mbit better. On Sun, Aug 25, 2013 at 11:30 AM, Fred Stratton wrote= : > > 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 doe= s > 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 recommen= d > 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, bes= t > 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 whil= e > testing? I am especially interested in CRC errors and ES SES and HEC, jus= t > 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 <=3D 50% of t= he > 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 a= n > 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.atlow= er snr. " so sync at 12162 might be too aggressive, no? But the point is > that as I understand iPlayer works fine without competing download traffi= c? > 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 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 fo= r > 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 chipset > and software blob with a DSLAM which returns BDCM when interrogated. > > > > > >> > >>> 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:81un= dthe following tab chain Status -> Realtime Graphs -> Traffic -> Realtime > Traffic. If during your test the Outbound rate stays well below you shape= d > limit and you still encounter the stream failure I would say it is save t= o > 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% a= nd > 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 re= al > time trace looks perfectly normal. > > iPlayer is a Flash based player which is web page embedded. The 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 o= f > 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 continue, 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 AQ= M > 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=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 standar= d > 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 tw= o > steps, so cover a range > 2 ATM cells (so > 96 bytes) > >>> SWEEPMINSIZE=3D16 # 64bit systems seem to require 16 byte= s > 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 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 migh= t > 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 i= s > 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 b= e > 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 fo= r > 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, wit= h > 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 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 fo= r > UDP floods :) ) > > > > [snipp] > > > > > > Best Regards > > Sebastian > > _______________________________________________ > 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 --f46d043c820c64b9d704e4c9fcae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
So it sounds like you need a lower setting = for the download than what you are using? It's not the upload that is y= our problem.

Netanalyzer sends one packet stream and thus mea= sures 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 eve= ry opportunity.

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.

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

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> 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.
>
> =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@ima= p.cc> wrote:
>>>
>>>>
>>>> On 25 Aug 2013, at 10:21, Fred Stratton <fredstratton@i= map.cc> wrote:
>>>>
>>>>> 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. "= ; 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?

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.hom= e.lan:81und the following tab chain Status -> Realtime Graphs -> Traf= fic -> Realtime Traffic. If during your test the Outbound rate stays wel= l 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 issue= s.
>>
>> 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
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=20
--f46d043c820c64b9d704e4c9fcae--