From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (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 E41F321F0B3 for ; Tue, 7 Jan 2014 05:43:36 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id n16so129522oag.8 for ; Tue, 07 Jan 2014 05:43:36 -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=fbxR/FMtBPHqIOfzt7ppVngR5DML97msJAups4OFm70=; b=Mcq/LJNHp4rgcjEG2v6+EyFaZna64az0zT+meksV5hppw1xxjw+roLIrx1SYOwxgm8 0z03caEhagzNqtql0UF+V5MW5Oz4nRWfL6l4HA5MRE0StKCHhKRiTkL2/bXt0325i6es SMIckOhx3/QdPzMKjeI5NrpXNnprAVOBv7POERLDEtNBvCGWxNAKV3wC3IhGRHUgdg0p 8g3LOWQPn9pX+JkfhkSfwGRTOnUK0kjJ3co1JiejECQT58jZU6d1lqrVmEuFaSPmijHe Lo0wTcdTDvPT10FMjXYuGarkiU4JA9/vgRp3q7aGq6Q6WrSIIr7P0V2rWyv/8bGDhzaG nDAA== X-Received: by 10.60.65.5 with SMTP id t5mr77155959oes.19.1389102215995; Tue, 07 Jan 2014 05:43:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.194 with HTTP; Tue, 7 Jan 2014 05:43:15 -0800 (PST) In-Reply-To: <0605567F-B62E-4ABD-9F0A-156BB63328F6@gmx.de> References: <01558084-B7D8-448A-A4ED-CE36D18AAA97@gmail.com> <52C855B1.1040209@imap.cc> <52CA7CC3.2030203@imap.cc> <52CABC11.6040000@imap.cc> <0605567F-B62E-4ABD-9F0A-156BB63328F6@gmx.de> From: David Personette Date: Tue, 7 Jan 2014 08:43:15 -0500 Message-ID: To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a11c1d6a82427a704ef619043 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 13:44:08 -0000 --001a11c1d6a82427a704ef619043 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sebastian, I have both Linux and Mac (all my systems are Linux, the Mac is my work laptop). I don't have Matlab, so I'll try to get it working in Octave (haven't really used it before). If it's something that can help others in the community, then I'll definitely run it. Assuming that I don't forget, I'll run it tonight and have it for you tomorrow. Thanks for the clear explanations. --=20 David P. On Tue, Jan 7, 2014 at 8:02 AM, Sebastian Moeller wrote: > Hi David, > > > On Jan 7, 2014, at 13:11 , David Personette wrote: > > > 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 neve= r > seen it in the modems config (in the brief period it has an IP before I p= ut > it in bridge mode as well so the routable IP goes to my actual router), o= r > needed to configure it on my router. > > Ah, so there are 2 major variations of "bridged": > 1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet 14, possibly FCS > - 4+padding) > 2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibly FCS - > 4+padding) > (he FCS padding potentially turns this into 4 variations, but it should b= e > really rare, or so I heard). > > You could just slowly reduce the overhead and see how the link > behaves; honestly I do not know how prominent a slight overhead > underestimate would feel, so by all means go ahead and try :). If you hav= e > a mac or linux computer on your network, you could try to measure the > overhead with the attached ping_sweeper5_dp.sh script (needs editing). Th= en > you could run tc_stab_parameter_guide_04.m in matlab or octave (on the > matlab command prompt change into the directory containing the script and > the log file run "[ tmp ] =3D tc_stab_parameter_guide_04( fullfile(pwd, > 'ping_sweep_ADSL2_20140104_122844.txt'))" ; make sure to replace > ping_sweep_ADSL2_20140104_122844.txt with the name of your log file. The > measurement will take around 3 hours (for 10000 samples per size, for you= r > link 1000 would be enough) and wants an undisturbed network (I typically > run this over night); the parsing of the log file will also consume 20 > minutes or more, the actual analysis will take a few seconds=E2=80=A6 > If you go that route I would love it if you could share your log > file, since I only have one old bridged LLC/SNAP example. (I intend to pu= t > all scripts and an instruction on the wiki, with example plots for the > different results). > > > Best Regards > Sebastian > > > > > > > > > > > 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. > > > > -- > > 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 > 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 m= y > 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 sinc= e > 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 > is right for a typical PPPoE over LLC/SNAP connection, if that is correct > for your link you are fine, otherwise contact me if you want to empirical= ly > 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 > router will automatically take care of the ATM cell overhead for you > (basically reducing the effective rate to ~90% of the link, in other word= s > you get the same effect by shaping to 90%). It will also handle the per > packet overhead and the nasty potential padding of the last ATM cell (bot= h > 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 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 li= nk > 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 settin= g > up the ATM overhead earlier. > > > > Oh, I can understand, when I learned about this some years ago > (by 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 > is 12.1 decibel. I am using 11000/950 kb/s as settings. > > > > > > So 100 * 11000 / 11744 =3D 93.66% of downlink line rate and 1= 00* > 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 > 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 > > > 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 o= f > 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? And 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 underestimat= e > 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 b= e > made > > > >>>>> consistently. > > > >>>> Well, what I was aiming for was for us to get the sqm scripts an= d > 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 revelatio= ns > > > >>>> I've been going around saying that "friends don't let friends ru= n > > > >>>> factory firmware". I would like a stable build of sqm and cerowr= t > to > > > >>>> emerge, and to then go off and work on improving wifi. Regrettab= ly > > > >>>> what seems to be happening is more backwards than forwards on th= e > > > >>>> former, and ramping up on the ath9k and ath10k is taking more ti= me > > > >>>> 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. > > > >>>> > > > >>>>> I concur with your ADSL setup suggestion as default. I have bee= n > 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. > > > >>>> > > > >>>>> 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 = the 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 cle= ar > > > >>>>>> recommendation that would be optimal for their equipment. > Consequently, I > > > >>>>>> believe the best we can do is come up with =E2=80=9Cgood enoug= h=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=9CSettin= g 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 = Packet > Overhead to > > > >>>>>> 40 > > > >>>>>> VDSL2 link: Choose =E2=80=9CVDSL=E2=80=9D, and set Per= Packet Overhead > to 8 > > > >>>>>> Other kind of link (e.g., Cable, Fiber, Ethernet, othe= r > 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 t= o > 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 > > > > > > > > > > --001a11c1d6a82427a704ef619043 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sebastian,

I have both Linux and Mac (all my sys= tems are Linux, the Mac is my work laptop). I don't have Matlab, so I&#= 39;ll try to get it working in Octave (haven't really used it before). = If it's something that can help others in the community, then I'll = definitely run it. Assuming that I don't forget, I'll run it tonigh= t and have it for you tomorrow. Thanks for the clear explanations.

--
David P.


On Tue, Jan 7, 2014 at 8:02 AM, Seba= stian Moeller <moeller0@gmx.de> wrote:
Hi David,


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

> I was going to test the recommended bridge settings for overhead (32 I= IRC), because as far as I can tell there is no PPPoE involved. I've nev= er 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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ah, so there are 2 major variations of &q= uot;bridged":
1) =C2=A0 =C2=A0 =C2=A0LLC/SNAP: =C2=A0 =C2=A0 =C2=A0 Bridged - 32 (ATM - 1= 8, ethernet 14, possibly FCS - 4+padding)
2) =C2=A0 =C2=A0 =C2=A0VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibl= y FCS - 4+padding)
(he FCS padding potentially turns this into 4 variations, but it should be = really rare, or so I heard).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 You could just slowly reduce the overhead and s= ee how the link behaves; honestly I do not know how prominent a slight over= head underestimate would feel, so by all means go ahead and try :). If you = have a mac or linux computer on your network, you could try to measure the = overhead with the attached ping_sweeper5_dp.sh script (needs editing). Then= you could run tc_stab_parameter_guide_04.m in matlab or octave (on the mat= lab command prompt change into the directory containing the script and the = log file run "[ tmp ] =3D tc_stab_parameter_guide_04( fullfile(pwd, &#= 39;ping_sweep_ADSL2_20140104_122844.txt'))" ; make sure to replace= ping_sweep_ADSL2_20140104_122844.txt with the name of your log file. The m= easurement will take around 3 hours (for 10000 samples per size, for your l= ink 1000 would be enough) and wants an undisturbed network (I typically run= this over night); the parsing of the log file will also consume 20 minutes= or more, the actual analysis will take a few seconds=E2=80=A6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you go that route I would love it if you cou= ld share your log file, since I only have one old bridged LLC/SNAP example.= (I intend to put all scripts and an instruction on the wiki, with example = plots for the different results).


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







>
> I am seeing my effective bandwidth be higher by about 50/KBs on downlo= ads. 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 ar= e working flawlessly for hours.
>
> --
> David P.
>
>
>
> On Tue, Jan 7, 2014 at 6:34 AM, Sebastian 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 i= nternet options are DSL and satellite. The local provider is Century Link (= it used to be Sprint, but they sold their copper phone business off). I hav= e 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 perc= entage 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 outsi= de 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 perio= ds 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,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The exact number depends on the encapsulat= ion your ISP uses, 40 is right for a typical PPPoE over LLC/SNAP connection= , if that is correct for your link you are fine, otherwise contact me if yo= u 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 contr= ol 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 l= ink layer ATM the router will automatically take care of the ATM cell overh= ead 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 handle= the per packet overhead and the nasty potential padding of the last ATM ce= ll (both have a stronger effect on small packets and are hard to actually a= ccount for by static rate reduction; link layer ATM comes again to the resc= ue by taking these two into account individually for each packet based on t= he 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 li= nk 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 abou= t setting up the ATM overhead earlier.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Oh, I can understand, when I learned about= this some years ago (by stumbling over Russel Stuart's website and Jes= per Brouer's thesis) it immediate changed my internet experience (I was= 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 mome= nt. SNR 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 = downlink line rate and 100* 950 / 1022 =3D 92.95 % of uplink line rate; qui= te impressive given the common wisdom of 85% :).
> >
> >
> > > =C2=A0I shall try your suggestion when there is something wo= rth watching live, to provide a valid comparison, which may not be before 2= 1:30 CET on Sunday.
> >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Oh, take your time, this is really no= t essential, butit would be a nice data point for figuring out how importan= t 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 <fredstratto= n@imap.cc> wrote:
> > >>
> > >>> I have been operating the latest build with 6relayd = disabled. The henet /48 I have been allocated is subnetted correctly, presu= mably by dnsmasq.
> > >>>
> > >>> I adopted the suggestions to use nfq_codel and an eg= ress target of 25ms , with an overhead of 40 on a PPPoE connection. =C2=A0I= chose to watch the first 2 episodes of the 3 part third series of 'She= rlock', live on iPlayer, and these streamed correctly and uninterrupted= for 90 minutes. =C2=A0This was not previously possible. =C2=A0(Quite wheth= er they were up to the standard of previous episodes is another matter.) > > >>>
> > >>> I can watch iPlayer with little stutter whilst downl= oading Arch Linux by torrent, downloading other files at the same time.
> > >>>
> > >>> So, for a relatively slow ADSL2+ line, the current b= uild works well.
> > >> =C2=A0 =C2=A0 =C2=A0Out of curiosity, to what percentage= of the "current line rate" (you know the one reported by your mo= dem) you shaped up- and downlink? And in case you have too much time on you= r hand, how does the same feel with an overhead of 10 (to see how bad an ov= erhead 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 &= lt;fredstratton@imap.cc> wrote:
> > >>>>> Link Names:
> > >>>>>
> > >>>>> For consistency, if ADSL is used as a portma= nteau term, them VDSL should be
> > >>>>> used as the equivalent for VDSL and VDSL2. > > >>>>>
> > >>>>> CeroWRT has to decide whether it is an exper= imental build, or something that
> > >>>>> will eventually be used in production, so th= ese decisions can be made
> > >>>>> consistently.
> > >>>> Well, what I was aiming for was for us to get th= e sqm scripts and gui
> > >>>> up to where they were better than the standard o= penwrt qos scripts and
> > >>>> then push them up to openwrt to where they could= be more widely
> > >>>> deployed.
> > >>>>
> > >>>> Aside from being able to dynamically assign prio= rities in the gui, we
> > >>>> are there. =C2=A0Except that nfq_codel is curren= tly getting better results
> > >>>> than fq_codel at low bandwidths, and I'm tem= pted to pour all of
> > >>>> simple.qos into C.
> > >>>>
> > >>>> As for cero's future - certainly since all t= he snowden revelations
> > >>>> I've been going around saying that "fri= ends don't let friends run
> > >>>> factory firmware". I would like a stable bu= ild 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 tha= n forwards on the
> > >>>> former, and ramping up on the ath9k and ath10k i= s 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 awa= y" 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 o= n cero, and getting 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 c= alculate ADSL overhead for the
> > >>>>> last several days. After several hours of cu= rve fitting using Octave, an
> > >>>>> overhead result is displayed. This novel app= roach works well.
> > >>>> It would be nice to get to where we could autoco= nfigure a router using
> > >>>> tools like these with no human intervention. Thi= s includes bandwidth
> > >>>> estimation.
> > >>>>
> > >>>>> The overhead for the particular setup I use = was 40 for PPPoE, and 10 for
> > >>>>> PPPoA.
> > >>>>>
> > >>>>> The default you suggest is a suitable starti= ng 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 the Link Layer
> > >>>>>> Adaptation overhead descriptions and rec= ommendations. In an earlier message,
> > >>>>>> (see
> > >>>>>> https= ://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html<= /a>
> > >>>>>> and following messages), Fred Stratton d= escribed the overheads carried by
> > >>>>>> various options, and Sebastian Moeller a= lso 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 wi= th =E2=80=9Cgood enough=E2=80=9D recommendations
> > >>>>>> that are not wrong, and still give decen= t 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_CeroWrt_310<= /a>
> > >>>>>>
> > >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ADSL/ATM lin= k: Choose =E2=80=9CADSL/ATM", and set Per Packet Overhead to
> > >>>>>> 40
> > >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 VDSL2 link: = Choose =E2=80=9CVDSL=E2=80=9D, and set Per Packet Overhead to 8
> > >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Other kind o= f link (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 descriptio= n. I would ask that we change to GUI to reflect
> > >>>>>> those names as well. This makes it far e= asier/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/li= stinfo/cerowrt-devel
> > >>>>> ____________________________________________= ___
> > >>>>> Cerowrt-devel mailing list
> > >>>>> Cerowrt-devel@lists.bufferbloat.net
> > >>>>> https://lists.bufferbloat.net/listin= fo/cerowrt-devel
> > >>>>
> > >>> _______________________________________________
> > >>> Cerowrt-devel mailing list
> > >>> Cerowrt-devel@lists.bufferbloat.net
> > >>> https://lists.bufferbloat.net/listinfo/cerow= rt-devel
> > >
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-de= vel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel<= br> > >
>
>



--001a11c1d6a82427a704ef619043--