[Cerowrt-devel] some kernel updates

[Dave Taht]

Netanalyzer is not useful in a fq_codel'ed system.


On Sun, Aug 25, 2013 at 10:53 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:

> Hi Fred,
>
>
> On Aug 25, 2013, at 16:26 , Fred Stratton <fredstratton at 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.
>
>         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 <moeller0 at gmx.de> wrote:
> >
> >> Hi Fred,
> >>
> >>
> >> On Aug 25, 2013, at 12:17 , Fred Stratton <fredstratton at imap.cc> wrote:
> >>
> >>>
> >>> On 25 Aug 2013, at 10:21, Fred Stratton <fredstratton at imap.cc> 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.atlower 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:81undthe 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
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130825/a1c03262/attachment-0001.html>