[Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads
Fred Stratton
fredstratton at imap.cc
Tue Jan 7 09:53:11 EST 2014
Some comments about procedure. I mention the distro I currently use, so
one aspect is distro specific:
Choose a server which actually returns pings. I used 'mtr' on one run to
choose a server, but did not check it with ping. A mistake.
The data collection run took circa 5 hours. The resultant data file is
at ~/ , as you would expect.
Octave has a graphical front end to manipulate it, qtOctave, available
via Ubuntu Software Centre. I ran this combo under Ubuntu 13.10, on a
NUC with a Sandy Bridge Celeron processor. The parsing of the data file
took 5-6 hours, and the actual calculation 20 or 30 seconds at the end.
The initial process produces a *.mat file, so, if required,
recalculation time is short.
You will appreciate that linux systems produce graphs that are not
necessarily easily saved. I used the Print Screen key and trimmed the
*.png file with a graphics program -Pinta.
On 07/01/14 13:43, David Personette wrote:
> 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.
>
> --
> David P.
>
>
>
> On Tue, Jan 7, 2014 at 8:02 AM, Sebastian Moeller <moeller0 at gmx.de
> <mailto:moeller0 at gmx.de>> wrote:
>
> Hi David,
>
>
> On Jan 7, 2014, at 13:11 , David Personette <dperson at gmail.com
> <mailto:dperson at gmail.com>> 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 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.
>
> 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 be 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 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 matlab
> command prompt change into the directory containing the script and
> the log file run "[ tmp ] = 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 your 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…
> 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 put 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
> <moeller0 at gmx.de <mailto:moeller0 at gmx.de>> wrote:
> > Hi David,
> >
> >
> > On Jan 7, 2014, at 12:08 , David Personette <dperson at gmail.com
> <mailto: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 <mailto: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
> <mailto:Cerowrt-devel at lists.bufferbloat.net>
> > > >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > > >>>>> _______________________________________________
> > > >>>>> Cerowrt-devel mailing list
> > > >>>>> Cerowrt-devel at lists.bufferbloat.net
> <mailto:Cerowrt-devel at lists.bufferbloat.net>
> > > >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > > >>>>
> > > >>> _______________________________________________
> > > >>> Cerowrt-devel mailing list
> > > >>> Cerowrt-devel at lists.bufferbloat.net
> <mailto:Cerowrt-devel at lists.bufferbloat.net>
> > > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > > >
> > >
> > > _______________________________________________
> > > Cerowrt-devel mailing list
> > > Cerowrt-devel at lists.bufferbloat.net
> <mailto: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/80640d6f/attachment-0002.html>
More information about the Cerowrt-devel
mailing list