Hi Dave,
thanks a lot for the explanation.
On Jan 6, 2014, at 16:03 , Dave Taht <dave.t...@gmail.com> wrote:
>
> On Jan 6, 2014 5:56 AM, "Sebastian Moeller" <moell...@gmx.de> wrote:
> >
> > Hi Dave, hi List,
> >
> > On Jan 6, 2014, at 04:29 , Dave Taht <dave.t...@gmail.com> wrote:
> >
> > > On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton <fredstrat...@imap.cc>
> > > wrote:
> > >> Link Names:
> > >>
> > >> For consistency, if ADSL is used as a portmanteau term, them VDSL should
> > >> be
> > >> used as the equivalent for VDSL and VDSL2.
> > >>
> > >> CeroWRT has to decide whether it is an experimental build, or something
> > >> that
> > >> will eventually be used in production, so these decisions can be made
> > >> consistently.
> > >
> > > Well, what I was aiming for was for us to get the sqm scripts and gui
> > > up to where they were better than the standard openwrt qos scripts and
> > > then push them up to openwrt to where they could be more widely
> > > deployed.
> > >
> > > Aside from being able to dynamically assign priorities in the gui, we
> > > are there. Except that nfq_codel is currently getting better results
> > > than fq_codel at low bandwidths, and I'm tempted to pour all of
> > > simple.qos into C.
> >
> > Since you wore nfq_codel, what is the secret sauce here?
>
> 1) It uses a 'tighter' version of Codel than what is currently in Linux. It
> doesn't work as well on longer rtts but holds down queue lengths at shorter
> rtts better and responds quicker than normal codel.
>
> This is a slightly more expensive version of codel too in that it uses two
> invsqrt via newtons method to get more accurate results.
>
> 2) it rotates the flow list more like how sfq does yielding better mixing
> which leads to higher survival rates for sparse flows and more balance across
> all flows.
>
> (This is a one line change to fq-codel)
>
> At higher bandwidths (say, 50mbit) being more drr like (fqcodel) actually
> tends to do better than sfqlike as bunching up some packet deliveries makes
> hosts respond quicker.
>
> 3) common to all the codels in this was elimination of the maxpacket check
> which mildly increases drop probability.
>
> Compared to the orders of magnitude we already get from fq codel the sum
> benefit of these fixes is in the very small percentage points. Without an
> extensive testing and simulation campaign I've been reluctant to attempt
> pushing them upstream. What I have mostly thought about instead was bundling
> up simple.QoS into c (call it cake or broadbandeq),
> Using these mods, adding in fixes for things that are hard now, like full
> diffserv support and something lighter than htb.
>
> But enotime, funding etc. Until 3 hit seeing benefit from nfqcodel was even
> harder to see, and I'd like to drop out 3 and revisit the data to see if the
> improvement is a chimera or not.
In case 3) and potentially 2 are the critical parts, do you see a
chance of getting these included upstream as part of fq_codels that need
special tc options to trigger? I assume 1 to be larger and potentially harder
to sell upstream (then again since codel is intended to run knob-free, maybe
even adding 2 and 3 is controversial...).
Best Regards
Sebastian
>
> > >
> > > As for cero's future - certainly since all the snowden revelations
> > > I've been going around saying that "friends don't let friends run
> > > factory firmware". I would like a stable build of sqm and cerowrt to
> > > emerge, and to then go off and work on improving wifi. Regrettably
> > > what seems to be happening is more backwards than forwards on the
> > > former, and ramping up on the ath9k and ath10k is taking more time
> > > than I'd like, and it seems likely I'll be working on those primarily
> > > on another platform and only eventually pushing the results out to
> > > cero, mainline kernel
> > >
> > > So it's still at the "keep plugging away" point for sqm, ipv6, cero in
> > > general, with the stable release always just out of sight.
> > >
> > > Tackling the ipv6 problem is next on my agenda on cero, and getting a
> > > test suite going is next on my day job.
> >
> > Any further hints on the nature of your day job possible :)
> >
> > >
> > >> I concur with your ADSL setup suggestion as default. I have been running
> > >> the
> > >> Sebastian Moeller ping script overnight to calculate ADSL overhead for
> > >> the
> > >> last several days. After several hours of curve fitting using Octave, an
> > >> overhead result is displayed. This novel approach works well.
> > >
> > > It would be nice to get to where we could autoconfigure a router using
> > > tools like these with no human intervention. This includes bandwidth
> > > estimation.
> >
> > I fully agree that it would be nice. Also it ail e hard unless we
> > take control over the actual bottleneck link… With DSL connections, the DSL
> > modem knows a lot about the link properties, if the modem would be onboard
> > we could programmatically as about bandwidth and encapsulation; for the
> > more typical case with an independent modem or even modem router we have no
> > clear path accessing that information. With cable I have even less hope, as
> > will never get the modem into the router (then again DOCSIS 3.1's typically
> > faster speeds and mandatory pie in the modem might make the situation less
> > dire than on the DSL side).
> > So for ATM based links, I think we can estimate a number of
> > relevant parameters about encapsulation and an aggregate up- and
> > down-bandwidth measurement (which alas is not too helpful unless we know
> > the degree of asymmetry or one of the bandwidth, in both cases we are
> > likely to know everything a priori anyway). But the current prototype code
> > I have is really slow (3 hours measurement time with otherwise quiet home
> > network; ~20 processing) and memory demanding (the ascii ping traces take
> > up ~260MB) so will not be able to run on the router (also the current
> > implementation in matlab/octave does not lend itself well for an embedded
> > platform…)
> >
> > Best Regards
> > Sebastian
> >
> >
> > >
> > >> The overhead for the particular setup I use was 40 for PPPoE, and 10 for
> > >> PPPoA.
> > >>
> > >> The default you suggest is a suitable starting point, I suggest.
> > >>
> > >>
> > >> On 04/01/14 18:16, Rich Brown wrote:
> > >>>
> > >>> QUESTION #5: I still don’t have any great answers for the Link Layer
> > >>> Adaptation overhead descriptions and recommendations. In an earlier
> > >>> message,
> > >>> (see
> > >>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
> > >>> and following messages), Fred Stratton described the overheads carried
> > >>> by
> > >>> various options, and Sebastian Moeller also gave some useful advice.
> > >>>
> > >>> After looking at the options, I despair of giving people a clear
> > >>> recommendation that would be optimal for their equipment. Consequently,
> > >>> I
> > >>> believe the best we can do is come up with “good enough” recommendations
> > >>> that are not wrong, and still give decent performance.
> > >>>
> > >>> In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
> > >>> reflect this understanding. See
> > >>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
> > >>>
> > >>> ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to
> > >>> 40
> > >>> VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
> > >>> Other kind of link (e.g., Cable, Fiber, Ethernet, other not
> > >>> listed): Choose “None (default)”, and set Per Packet Overhead to 0
> > >>>
> > >>> NB: I have changed the first menu choice to “ADSL/ATM” and the second to
> > >>> “VDSL” in the description. I would ask that we change to GUI to reflect
> > >>> those names as well. This makes it far easier/less confusing to talk
> > >>> about
> > >>> the options.
> > >>>
> > >>> As always, I welcome help in setting out clear recommendations that work
> > >>> well for the vast majority of people who try CeroWrt. Thanks.
> > >>>
> > >>> Rich
> > >>> _______________________________________________
> > >>> Cerowrt-devel mailing list
> > >>> Cerowrt-devel@lists.bufferbloat.net
> > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>
> > >>
> > >> _______________________________________________
> > >> Cerowrt-devel mailing list
> > >> Cerowrt-devel@lists.bufferbloat.net
> > >> 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
> > > Cerowrt-devel@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
