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 <[email protected]
<mailto:[email protected]>> wrote:
Hi David,
On Jan 7, 2014, at 13:11 , David Personette <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
> Hi David,
>
>
> On Jan 7, 2014, at 12:08 , David Personette <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
> > Hi Fred,
> >
> >
> > On Jan 6, 2014, at 15:22 , Fred Stratton
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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
> > >>>>>> [email protected]
<mailto:[email protected]>
> > >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>>>> _______________________________________________
> > >>>>> Cerowrt-devel mailing list
> > >>>>> [email protected]
<mailto:[email protected]>
> > >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>>>
> > >>> _______________________________________________
> > >>> Cerowrt-devel mailing list
> > >>> [email protected]
<mailto:[email protected]>
> > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > [email protected]
<mailto:[email protected]>
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
