[Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads

David Personette dperson at gmail.com
Tue Jan 7 07:11:35 EST 2014


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.

-- 
David P.



On Tue, Jan 7, 2014 at 6:34 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:

> Hi David,
>
>
> On Jan 7, 2014, at 12:08 , David Personette <dperson at gmail.com> 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 used
> 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.
>
>         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 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 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 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 router
> 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 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 (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 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 (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 <moeller0 at gmx.de>
> wrote:
> > Hi Fred,
> >
> >
> > On Jan 6, 2014, at 15:22 , Fred Stratton <fredstratton at imap.cc> 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 = 93.66% of downlink line rate and 100*
> 950 / 1022 = 92.95 % of uplink line rate; quite impressive given the common
> 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…
> >
> > Best Regards
> >         Sebastian
> >
> > >
> > > On 06/01/14 14:12, Sebastian Moeller wrote:
> > >> Hi Fred,
> > >>
> > >>
> > >> On Jan 6, 2014, at 10:52 , Fred Stratton <fredstratton at imap.cc>
> 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 the
> first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer,
> 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 underestimate would feel for a
> user), since you currently happen to have a quite sensitive subjective
> latency evaluation system set up :)…
> > >>
> > >> Best Regards
> > >>      Sebastian
> > >>
> > >>>
> > >>> On 06/01/14 03:29, Dave Taht wrote:
> > >>>> On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton <fredstratton at 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.
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>>> 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.
> > >>>>
> > >>>>> 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 at lists.bufferbloat.net
> > >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>>>> _______________________________________________
> > >>>>> Cerowrt-devel mailing list
> > >>>>> Cerowrt-devel at lists.bufferbloat.net
> > >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>>>
> > >>> _______________________________________________
> > >>> Cerowrt-devel mailing list
> > >>> Cerowrt-devel at lists.bufferbloat.net
> > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140107/323d125b/attachment-0002.html>


More information about the Cerowrt-devel mailing list