From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 83DD521F18F for ; Tue, 7 Jan 2014 04:11:56 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wn1so50520obc.33 for ; Tue, 07 Jan 2014 04:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yX2RKLdhsSZet3fwdMicxOIHIVKF+VI84316prLnOJQ=; b=UH1hb3aEglpWQWwLobFurxMMCQyS7xg3+h2Xas0KcxVhRMfk6NsOJP6XUe1KQGjAoW rDHMtZOP0Sc11xQ8Ets52SNnQcYSImysOt2PnvYOuHXsBH8eMWXgHLm10BVoperEXLFZ FdgNpReCNviOqfD8WWFur/6p8//bmYFDiEzr6v4CTSKzD11/efg3XtPHVOhZ50i38V+W U3a5V3O3kyiA+2nK+Et4uG1O04n2MDm/Dhk/dE2EHftk5m61B0STej2XoO+Jbbrn8FW/ uOlvtIwU5cuRlySPtMhVZffxlebvNsv5EURrPq6zMrcxM6KejyzDLNlg6JFYYHFm0jcc zCSA== X-Received: by 10.60.99.8 with SMTP id em8mr51022577oeb.8.1389096715603; Tue, 07 Jan 2014 04:11:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.194 with HTTP; Tue, 7 Jan 2014 04:11:35 -0800 (PST) In-Reply-To: References: <01558084-B7D8-448A-A4ED-CE36D18AAA97@gmail.com> <52C855B1.1040209@imap.cc> <52CA7CC3.2030203@imap.cc> <52CABC11.6040000@imap.cc> From: David Personette Date: Tue, 7 Jan 2014 07:11:35 -0500 Message-ID: To: Sebastian Moeller Content-Type: multipart/alternative; boundary=047d7b33cad24ad27804ef6048c7 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads 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: Tue, 07 Jan 2014 12:12:11 -0000 --047d7b33cad24ad27804ef6048c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was going to test the recommended bridge settings for overhead (32 IIRC), because as far as I can tell there is no PPPoE involved. I've never seen it in the modems config (in the brief period it has an IP before I put it in bridge mode as well so the routable IP goes to my actual router), or needed to configure it on my router. I am seeing my effective bandwidth be higher by about 50/KBs on downloads. On Netflix, my Roku used to try HD upon starting playback then (after 20-30 seconds thinking about it) fail back to SD, but now the HD streams are working flawlessly for hours. --=20 David P. On Tue, Jan 7, 2014 at 6:34 AM, Sebastian Moeller wrote: > Hi David, > > > On Jan 7, 2014, at 12:08 , David Personette wrote: > > > I'm in the US, but live in a relatively rural area. My only internet > options are DSL and satellite. The local provider is Century Link (it use= d > to be Sprint, but they sold their copper phone business off). I have the > fastest service that they offer (based on distance from the DSLAM), 4 dow= n > / .5 up. > > And you are not alone, a considerable percentage of the populatio= n > wherever you look is hanging on such connections. So cerowrt should reall= y > help those folk as well as luckier ones. > > > > > I have had SmokePing monitoring my latency to the first hop outside my > network for over a year now (I've been on CeroWRT the whole time). My > baseline (no load) latency is 31ms. I used to have AQM throttling back to > 80% of my already pathetic bandwidth. I would still regularly see periods > lasting minutes to hours when latency would be 80 - 120ms. > > > > I only recently grokked what you were talking about with tc_stab since = I > got back from the holidays with the family, I set things up as you > suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per > packet overhead 40, > > The exact number depends on the encapsulation your ISP uses, 40 i= s > right for a typical PPPoE over LLC/SNAP connection, if that is correct fo= r > your link you are fine, otherwise contact me if you want to empirically > find out the proper value for your link. > > > and set my SQM bandwidth limits to 95%). Since the 30th my "worst case" > latency has been 41ms. > > the fq_codels really are great if in control of the bottleneck, > really good work by bright people! > > > Plus I get to use more of my actual bandwidth. > > Well, that I am not so sure. By enabling link layer ATM the route= r > will automatically take care of the ATM cell overhead for you (basically > reducing the effective rate to ~90% of the link, in other words you get t= he > same effect by shaping to 90%). It will also handle the per packet overhe= ad > and the nasty potential padding of the last ATM cell (both have a stronge= r > effect on small packets and are hard to actually account for by static ra= te > reduction; link layer ATM comes again to the rescue by taking these two > into account individually for each packet based on the packet size). So > effectively 95% with link layer adjustments might mean a lower wire rate > than 80% without; the important thing is that with the link layer > adjustments the link capacity is estimated correctly avoiding the modem's > and the DSLAM's buffers to fill and cause buffer bloat. > > > I REALLY wish that I'd made the time to read your emails about setting > up the ATM overhead earlier. > > Oh, I can understand, when I learned about this some years ago (b= y > stumbling over Russel Stuart's website and Jesper Brouer's thesis) it > immediate changed my internet experience (I was on a 3 down / 0.5 up > connection at that time). :) > > Best Regards > Sebastian > > > > > Thank you. > > > > -- > > David P. > > > > > > > > On Mon, Jan 6, 2014 at 9:27 AM, Sebastian Moeller > wrote: > > Hi Fred, > > > > > > On Jan 6, 2014, at 15:22 , Fred Stratton wrote: > > > > > The line rate is 11744/1022 kb/s, but changes moment to moment. SNR i= s > 12.1 decibel. I am using 11000/950 kb/s as settings. > > > > So 100 * 11000 / 11744 =3D 93.66% of downlink line rate and 100= * > 950 / 1022 =3D 92.95 % of uplink line rate; quite impressive given the co= mmon > wisdom of 85% :). > > > > > > > I shall try your suggestion when there is something worth watching > live, to provide a valid comparison, which may not be before 21:30 CET on > Sunday. > > > > Oh, take your time, this is really not essential, butit would b= e > a nice data point for figuring out how important the correct overhead > estimate really is in real life, theory being theory and all=E2=80=A6 > > > > Best Regards > > Sebastian > > > > > > > > On 06/01/14 14:12, Sebastian Moeller wrote: > > >> Hi Fred, > > >> > > >> > > >> On Jan 6, 2014, at 10:52 , Fred Stratton > wrote: > > >> > > >>> I have been operating the latest build with 6relayd disabled. The > henet /48 I have been allocated is subnetted correctly, presumably by > dnsmasq. > > >>> > > >>> I adopted the suggestions to use nfq_codel and an egress target of > 25ms , with an overhead of 40 on a PPPoE connection. I chose to watch th= e > first 2 episodes of the 3 part third series of 'Sherlock', live on iPlaye= r, > and these streamed correctly and uninterrupted for 90 minutes. This was > not previously possible. (Quite whether they were up to the standard of > previous episodes is another matter.) > > >>> > > >>> I can watch iPlayer with little stutter whilst downloading Arch > Linux by torrent, downloading other files at the same time. > > >>> > > >>> So, for a relatively slow ADSL2+ line, the current build works well= . > > >> Out of curiosity, to what percentage of the "current line rate" > (you know the one reported by your modem) you shaped up- and downlink? An= d > in case you have too much time on your hand, how does the same feel with = an > overhead of 10 (to see how bad an overhead underestimate would feel for a > user), since you currently happen to have a quite sensitive subjective > latency evaluation system set up :)=E2=80=A6 > > >> > > >> Best Regards > > >> Sebastian > > >> > > >>> > > >>> On 06/01/14 03:29, Dave Taht wrote: > > >>>> On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton > 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. > > >>>> > > >>>> 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, cer= o > in > > >>>> general, with the stable release always just out of sight. > > >>>> > > >>>> Tackling the ipv6 problem is next on my agenda on cero, and gettin= g > a > > >>>> test suite going is next on my day job. > > >>>> > > >>>>> I concur with your ADSL setup suggestion as default. I have been > running the > > >>>>> Sebastian Moeller ping script overnight to calculate ADSL overhea= d > 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 bandwid= th > > >>>> estimation. > > >>>> > > >>>>> 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=E2=80=99t have any great answers for th= e Link > Layer > > >>>>>> Adaptation overhead descriptions and recommendations. In an > earlier message, > > >>>>>> (see > > >>>>>> > https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/00191= 4.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 =E2=80=9Cgood enough= =E2=80=9D > recommendations > > >>>>>> that are not wrong, and still give decent performance. > > >>>>>> > > >>>>>> In this spirit, I have changed Draft #3 of the =E2=80=9CSetting = up SQM=E2=80=9D > page to > > >>>>>> reflect this understanding. See > > >>>>>> > http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroW= rt_310 > > >>>>>> > > >>>>>> ADSL/ATM link: Choose =E2=80=9CADSL/ATM", and set Per Pa= cket > Overhead to > > >>>>>> 40 > > >>>>>> VDSL2 link: Choose =E2=80=9CVDSL=E2=80=9D, and set Per P= acket Overhead to > 8 > > >>>>>> Other kind of link (e.g., Cable, Fiber, Ethernet, other > not > > >>>>>> listed): Choose =E2=80=9CNone (default)=E2=80=9D, and set Per Pa= cket Overhead to 0 > > >>>>>> > > >>>>>> NB: I have changed the first menu choice to =E2=80=9CADSL/ATM=E2= =80=9D and the > second to > > >>>>>> =E2=80=9CVDSL=E2=80=9D in the description. I would ask that we c= hange 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 > > >>>> > > >>> _______________________________________________ > > >>> 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 > > > > --047d7b33cad24ad27804ef6048c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was going to test the recommended bridge settings f= or overhead (32 IIRC), because as far as I can tell there is no PPPoE invol= ved. I've never seen it in the modems config (in the brief period it ha= s an IP before I put it in bridge mode as well so the routable IP goes to m= y actual router), or needed to configure it on my router.

I am seeing my effective bandwidth be higher by about 50/KBs on d= ownloads. On Netflix, my Roku used to try HD upon starting playback then (a= fter 20-30 seconds thinking about it) fail back to SD, but now the HD strea= ms are working flawlessly for hours.

--
David P.
<= br>


On Tue, Jan 7, 2014 at 6:34 AM, Sebastia= n Moeller <moeller0@gmx.de> wrote:
Hi David,


On Jan 7, 2014, at 12:08 , David Personette <dperson@gmail.com> wrote:

> I'm in the US, but live in a relatively rural area. My only intern= et options are DSL and satellite. The local provider is Century Link (it us= ed to be Sprint, but they sold their copper phone business off). I have the= fastest service that they offer (based on distance from the DSLAM), 4 down= / .5 up.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 And you are not alone, a considerable per= centage of the population wherever you look is hanging on such connections.= So cerowrt should really help those folk as well as luckier ones.

>
> I have had SmokePing monitoring my latency to the first hop outside my= network for over a year now (I've been on CeroWRT the whole time). My = baseline (no load) latency is 31ms. I used to have AQM throttling back to 8= 0% of my already pathetic bandwidth. I would still regularly see periods la= sting minutes to hours when latency would be 80 - 120ms.
>
> I only recently grokked what you were talking about with tc_stab since= I got back from the holidays with the family, I set things up as you sugge= sted for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, = per packet overhead 40,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The exact number depends on the encapsula= tion your ISP uses, 40 is right for a typical PPPoE over LLC/SNAP connectio= n, if that is correct for your link you are fine, otherwise contact me if y= ou want to empirically find out the proper value for your link.

> and set my SQM bandwidth limits to 95%). Since the 30th my "worst= case" latency has been 41ms.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the fq_codels really are great if in cont= rol of the bottleneck, really good work by bright people!

> Plus I get to use more of my actual bandwidth.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Well, that I am not so sure. By enabling = link layer ATM the router will automatically take care of the ATM cell over= head for you (basically reducing the effective rate to ~90% of the link, in= other words you get the same effect by shaping to 90%). It will also handl= e the per packet overhead and the nasty potential padding of the last ATM c= ell (both have a stronger effect on small packets and are hard to actually = account for by static rate reduction; link layer ATM comes again to the res= cue by taking these two into account individually for each packet based on = the packet size). So effectively 95% with link layer adjustments might mean= a lower wire rate than 80% without; the important thing is that with the l= ink layer adjustments the link capacity is estimated correctly avoiding the= modem's and the DSLAM's buffers to fill and cause buffer bloat.

> I REALLY wish that I'd made the time to read your emails about set= ting up the ATM overhead earlier.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Oh, I can understand, when I learned abou= t this some years ago (by stumbling over Russel Stuart's website and Je= sper Brouer's thesis) it immediate changed my internet experience (I wa= s on a 3 down / 0.5 up connection at that time). :)

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = Sebastian

>
> Thank you.
>
> --
> David P.
>
>
>
> On Mon, Jan 6, 2014 at 9:27 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Fred,
>
>
> On Jan 6, 2014, at 15:22 , Fred Stratton <fredstratton@imap.cc> = wrote:
>
> > The line rate is 11744/1022 kb/s, but changes moment to moment. S= NR is 12.1 decibel. =C2=A0I am using 11000/950 kb/s as settings.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 So 100 * 11000 / 11744 =3D 93.66% of downl= ink line rate and 100* 950 / 1022 =3D 92.95 % of uplink line rate; quite im= pressive given the common wisdom of 85% :).
>
>
> > =C2=A0I shall try your suggestion when there is something worth w= atching live, to provide a valid comparison, which may not be before 21:30 = CET on Sunday.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Oh, take your time, this is really not ess= ential, butit would be a nice data point for figuring out how important the= correct overhead estimate really is in real life, theory being theory and = all=E2=80=A6
>
> Best Regards
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian
>
> >
> > On 06/01/14 14:12, Sebastian Moeller wrote:
> >> Hi Fred,
> >>
> >>
> >> On Jan 6, 2014, at 10:52 , Fred Stratton <fredstratton@ima= p.cc> wrote:
> >>
> >>> I have been operating the latest build with 6relayd disab= led. The henet /48 I have been allocated is subnetted correctly, presumably= by dnsmasq.
> >>>
> >>> I adopted the suggestions to use nfq_codel and an egress = target of 25ms , with an overhead of 40 on a PPPoE connection. =C2=A0I chos= e to watch the first 2 episodes of the 3 part third series of 'Sherlock= ', live on iPlayer, and these streamed correctly and uninterrupted for = 90 minutes. =C2=A0This was not previously possible. =C2=A0(Quite whether th= ey were up to the standard of previous episodes is another matter.)
> >>>
> >>> I can watch iPlayer with little stutter whilst downloadin= g Arch Linux by torrent, downloading other files at the same time.
> >>>
> >>> So, for a relatively slow ADSL2+ line, the current build = works well.
> >> =C2=A0 =C2=A0 =C2=A0Out of curiosity, to what percentage of t= he "current line rate" (you know the one reported by your modem) = you shaped up- and downlink? And in case you have too much time on your han= d, how does the same feel with an overhead of 10 (to see how bad an overhea= d underestimate would feel for a user), since you currently happen to have = a quite sensitive subjective latency evaluation system set up :)=E2=80=A6 > >>
> >> Best Regards
> >> =C2=A0 =C2=A0 =C2=A0Sebastian
> >>
> >>>
> >>> On 06/01/14 03:29, Dave Taht wrote:
> >>>> On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton <fr= edstratton@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 experiment= al build, or something that
> >>>>> will eventually be used in production, so these d= ecisions 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 openwr= t qos scripts and
> >>>> then push them up to openwrt to where they could be m= ore widely
> >>>> deployed.
> >>>>
> >>>> Aside from being able to dynamically assign prioritie= s in the gui, we
> >>>> are there. =C2=A0Except that nfq_codel is currently g= etting better results
> >>>> than fq_codel at low bandwidths, and I'm tempted = to pour all of
> >>>> simple.qos into C.
> >>>>
> >>>> As for cero's future - certainly since all the sn= owden revelations
> >>>> I've been going around saying that "friends = don't let friends run
> >>>> factory firmware". I would like a stable build o= f 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 for= wards on the
> >>>> former, and ramping up on the ath9k and ath10k is tak= ing more time
> >>>> than I'd like, and it seems likely I'll be wo= rking on those primarily
> >>>> on another platform and only eventually pushing the r= esults out to
> >>>> cero, mainline kernel
> >>>>
> >>>> So it's still at the "keep plugging away&quo= t; point for sqm, ipv6, cero in
> >>>> general, with the stable release always just out of s= ight.
> >>>>
> >>>> Tackling the ipv6 problem is next on my agenda on cer= o, and getting a
> >>>> test suite going is next on my day job.
> >>>>
> >>>>> I concur with your ADSL setup suggestion as defau= lt. I have been running the
> >>>>> Sebastian Moeller ping script overnight to calcul= ate ADSL overhead for the
> >>>>> last several days. After several hours of curve f= itting using Octave, an
> >>>>> overhead result is displayed. This novel approach= works well.
> >>>> It would be nice to get to where we could autoconfigu= re a router using
> >>>> tools like these with no human intervention. This inc= ludes bandwidth
> >>>> estimation.
> >>>>
> >>>>> The overhead for the particular setup I use was 4= 0 for PPPoE, and 10 for
> >>>>> PPPoA.
> >>>>>
> >>>>> The default you suggest is a suitable starting po= int, I suggest.
> >>>>>
> >>>>>
> >>>>> On 04/01/14 18:16, Rich Brown wrote:
> >>>>>> QUESTION #5: I still don=E2=80=99t have any g= reat answers for the Link Layer
> >>>>>> Adaptation overhead descriptions and recommen= dations. In an earlier message,
> >>>>>> (see
> >>>>>> https://li= sts.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html > >>>>>> and following messages), Fred Stratton descri= bed the overheads carried by
> >>>>>> various options, and Sebastian Moeller also g= ave some useful advice.
> >>>>>>
> >>>>>> After looking at the options, I despair of gi= ving people a clear
> >>>>>> recommendation that would be optimal for thei= r equipment. Consequently, I
> >>>>>> believe the best we can do is come up with = =E2=80=9Cgood enough=E2=80=9D recommendations
> >>>>>> that are not wrong, and still give decent per= formance.
> >>>>>>
> >>>>>> In this spirit, I have changed Draft #3 of th= e =E2=80=9CSetting up SQM=E2=80=9D page to
> >>>>>> reflect this understanding. See
> >>>>>> http://www= .bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 > >>>>>>
> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ADSL/ATM link: Ch= oose =E2=80=9CADSL/ATM", and set Per Packet Overhead to
> >>>>>> 40
> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 VDSL2 link: Choos= e =E2=80=9CVDSL=E2=80=9D, and set Per Packet Overhead to 8
> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Other kind of lin= k (e.g., Cable, Fiber, Ethernet, other not
> >>>>>> listed): Choose =E2=80=9CNone (default)=E2=80= =9D, and set Per Packet Overhead to 0
> >>>>>>
> >>>>>> NB: I have changed the first menu choice to = =E2=80=9CADSL/ATM=E2=80=9D and the second to
> >>>>>> =E2=80=9CVDSL=E2=80=9D 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 clea= r 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/listinf= o/cerowrt-devel
> >>>>> _______________________________________________ > >>>>> Cerowrt-devel mailing list
> >>>>> Cerowrt-devel@lists.bufferbloat.net
> >>>>> https://lists.bufferbloat.net/listinfo/ce= rowrt-devel
> >>>>
> >>> _______________________________________________
> >>> Cerowrt-devel mailing list
> >>> Ce= rowrt-devel@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/cerowrt-de= vel
> >
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@l= ists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>


--047d7b33cad24ad27804ef6048c7--