<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Some comments about procedure. I mention the distro I currently use,
so one aspect is distro specific:<br>
<br>
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.<br>
<br>
The data collection run took circa 5 hours. The resultant data file
is at ~/ , as you would expect.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/01/14 13:43, David Personette
wrote:<br>
</div>
<blockquote
cite="mid:CAMybZqyC+yVOxq4mO4paQJouKzYyADqKsywoBOuKMzNY6CjHoQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Sebastian,<br>
<br>
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.<br>
<div>
<div class="gmail_extra"><br clear="all">
<div>-- <br>
David P.</div>
<br>
<br>
<br>
<div class="gmail_quote">On Tue, Jan 7, 2014 at 8:02 AM,
Sebastian Moeller <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:moeller0@gmx.de"
target="_blank">moeller0@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi David,<br>
<div class="im"><br>
<br>
On Jan 7, 2014, at 13:11 , David Personette <<a
moz-do-not-send="true"
href="mailto:dperson@gmail.com">dperson@gmail.com</a>>
wrote:<br>
<br>
> 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.<br>
<br>
</div>
Ah, so there are 2 major variations of
"bridged":<br>
1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet
14, possibly FCS - 4+padding)<br>
2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14,
possibly FCS - 4+padding)<br>
(he FCS padding potentially turns this into 4
variations, but it should be really rare, or so I
heard).<br>
<br>
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…<br>
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).<br>
<br>
<br>
Best Regards<br>
<span class="HOEnZb"><font color="#888888">
Sebastian<br>
</font></span><br>
<br>
<br>
<br>
<br>
<br>
<br>
><br>
> 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.<br>
><br>
> --<br>
> David P.<br>
><br>
><br>
><br>
> On Tue, Jan 7, 2014 at 6:34 AM, Sebastian Moeller
<<a moz-do-not-send="true"
href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>>
wrote:<br>
> Hi David,<br>
><br>
><br>
> On Jan 7, 2014, at 12:08 , David Personette <<a
moz-do-not-send="true" href="mailto:dperson@gmail.com">dperson@gmail.com</a>>
wrote:<br>
><br>
> > 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.<br>
><br>
> 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.<br>
><br>
> ><br>
> > 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.<br>
> ><br>
> > 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,<br>
><br>
> 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.<br>
><br>
> > and set my SQM bandwidth limits to 95%). Since
the 30th my "worst case" latency has been 41ms.<br>
><br>
> the fq_codels really are great if in
control of the bottleneck, really good work by bright
people!<br>
><br>
> > Plus I get to use more of my actual bandwidth.<br>
><br>
> 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.<br>
><br>
> > I REALLY wish that I'd made the time to read
your emails about setting up the ATM overhead earlier.<br>
><br>
> 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). :)<br>
><br>
> Best Regards<br>
> Sebastian<br>
><br>
> ><br>
> > Thank you.<br>
> ><br>
> > --<br>
> > David P.<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Jan 6, 2014 at 9:27 AM, Sebastian
Moeller <<a moz-do-not-send="true"
href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>>
wrote:<br>
> > Hi Fred,<br>
> ><br>
> ><br>
> > On Jan 6, 2014, at 15:22 , Fred Stratton
<a class="moz-txt-link-rfc2396E" href="mailto:fredstratton@imap.cc"><fredstratton@imap.cc></a> wrote:<br>
> ><br>
> > > 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.<br>
> ><br>
> > 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% :).<br>
> ><br>
> ><br>
> > > 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.<br>
> ><br>
> > 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…<br>
> ><br>
> > Best Regards<br>
> > Sebastian<br>
> ><br>
> > ><br>
> > > On 06/01/14 14:12, Sebastian Moeller
wrote:<br>
> > >> Hi Fred,<br>
> > >><br>
> > >><br>
> > >> On Jan 6, 2014, at 10:52 , Fred
Stratton <a class="moz-txt-link-rfc2396E" href="mailto:fredstratton@imap.cc"><fredstratton@imap.cc></a> wrote:<br>
> > >><br>
> > >>> I have been operating the latest
build with 6relayd disabled. The henet /48 I have been
allocated is subnetted correctly, presumably by dnsmasq.<br>
> > >>><br>
> > >>> 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.)<br>
> > >>><br>
> > >>> I can watch iPlayer with little
stutter whilst downloading Arch Linux by torrent,
downloading other files at the same time.<br>
> > >>><br>
> > >>> So, for a relatively slow ADSL2+
line, the current build works well.<br>
> > >> 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 :)…<br>
> > >><br>
> > >> Best Regards<br>
> > >> Sebastian<br>
> > >><br>
> > >>><br>
> > >>> On 06/01/14 03:29, Dave Taht
wrote:<br>
> > >>>> On Sat, Jan 4, 2014 at 10:40
AM, Fred Stratton <a class="moz-txt-link-rfc2396E" href="mailto:fredstratton@imap.cc"><fredstratton@imap.cc></a> wrote:<br>
> > >>>>> Link Names:<br>
> > >>>>><br>
> > >>>>> For consistency, if ADSL
is used as a portmanteau term, them VDSL should be<br>
> > >>>>> used as the equivalent
for VDSL and VDSL2.<br>
> > >>>>><br>
> > >>>>> CeroWRT has to decide
whether it is an experimental build, or something that<br>
> > >>>>> will eventually be used
in production, so these decisions can be made<br>
> > >>>>> consistently.<br>
> > >>>> Well, what I was aiming for
was for us to get the sqm scripts and gui<br>
> > >>>> up to where they were better
than the standard openwrt qos scripts and<br>
> > >>>> then push them up to openwrt
to where they could be more widely<br>
> > >>>> deployed.<br>
> > >>>><br>
> > >>>> Aside from being able to
dynamically assign priorities in the gui, we<br>
> > >>>> are there. Except that
nfq_codel is currently getting better results<br>
> > >>>> than fq_codel at low
bandwidths, and I'm tempted to pour all of<br>
> > >>>> simple.qos into C.<br>
> > >>>><br>
> > >>>> As for cero's future -
certainly since all the snowden revelations<br>
> > >>>> I've been going around saying
that "friends don't let friends run<br>
> > >>>> factory firmware". I would
like a stable build of sqm and cerowrt to<br>
> > >>>> emerge, and to then go off
and work on improving wifi. Regrettably<br>
> > >>>> what seems to be happening is
more backwards than forwards on the<br>
> > >>>> former, and ramping up on the
ath9k and ath10k is taking more time<br>
> > >>>> than I'd like, and it seems
likely I'll be working on those primarily<br>
> > >>>> on another platform and only
eventually pushing the results out to<br>
> > >>>> cero, mainline kernel<br>
> > >>>><br>
> > >>>> So it's still at the "keep
plugging away" point for sqm, ipv6, cero in<br>
> > >>>> general, with the stable
release always just out of sight.<br>
> > >>>><br>
> > >>>> Tackling the ipv6 problem is
next on my agenda on cero, and getting a<br>
> > >>>> test suite going is next on
my day job.<br>
> > >>>><br>
> > >>>>> I concur with your ADSL
setup suggestion as default. I have been running the<br>
> > >>>>> Sebastian Moeller ping
script overnight to calculate ADSL overhead for the<br>
> > >>>>> last several days. After
several hours of curve fitting using Octave, an<br>
> > >>>>> overhead result is
displayed. This novel approach works well.<br>
> > >>>> It would be nice to get to
where we could autoconfigure a router using<br>
> > >>>> tools like these with no
human intervention. This includes bandwidth<br>
> > >>>> estimation.<br>
> > >>>><br>
> > >>>>> The overhead for the
particular setup I use was 40 for PPPoE, and 10 for<br>
> > >>>>> PPPoA.<br>
> > >>>>><br>
> > >>>>> The default you suggest
is a suitable starting point, I suggest.<br>
> > >>>>><br>
> > >>>>><br>
> > >>>>> On 04/01/14 18:16, Rich
Brown wrote:<br>
> > >>>>>> QUESTION #5: I still
don’t have any great answers for the Link Layer<br>
> > >>>>>> Adaptation overhead
descriptions and recommendations. In an earlier message,<br>
> > >>>>>> (see<br>
> > >>>>>> <a
moz-do-not-send="true"
href="https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html"
target="_blank">https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html</a><br>
> > >>>>>> and following
messages), Fred Stratton described the overheads carried
by<br>
> > >>>>>> various options, and
Sebastian Moeller also gave some useful advice.<br>
> > >>>>>><br>
> > >>>>>> After looking at the
options, I despair of giving people a clear<br>
> > >>>>>> recommendation that
would be optimal for their equipment. Consequently, I<br>
> > >>>>>> believe the best we
can do is come up with “good enough” recommendations<br>
> > >>>>>> that are not wrong,
and still give decent performance.<br>
> > >>>>>><br>
> > >>>>>> In this spirit, I
have changed Draft #3 of the “Setting up SQM” page to<br>
> > >>>>>> reflect this
understanding. See<br>
> > >>>>>> <a
moz-do-not-send="true"
href="http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310"
target="_blank">http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310</a><br>
> > >>>>>><br>
> > >>>>>> ADSL/ATM
link: Choose “ADSL/ATM", and set Per Packet Overhead to<br>
> > >>>>>> 40<br>
> > >>>>>> VDSL2 link:
Choose “VDSL”, and set Per Packet Overhead to 8<br>
> > >>>>>> Other kind of
link (e.g., Cable, Fiber, Ethernet, other not<br>
> > >>>>>> listed): Choose “None
(default)”, and set Per Packet Overhead to 0<br>
> > >>>>>><br>
> > >>>>>> NB: I have changed
the first menu choice to “ADSL/ATM” and the second to<br>
> > >>>>>> “VDSL” in the
description. I would ask that we change to GUI to
reflect<br>
> > >>>>>> those names as well.
This makes it far easier/less confusing to talk about<br>
> > >>>>>> the options.<br>
> > >>>>>><br>
> > >>>>>> As always, I welcome
help in setting out clear recommendations that work<br>
> > >>>>>> well for the vast
majority of people who try CeroWrt. Thanks.<br>
> > >>>>>><br>
> > >>>>>> Rich<br>
> > >>>>>>
_______________________________________________<br>
> > >>>>>> Cerowrt-devel mailing
list<br>
> > >>>>>> <a
moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> > >>>>>> <a
moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
> > >>>>>
_______________________________________________<br>
> > >>>>> Cerowrt-devel mailing
list<br>
> > >>>>> <a
moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> > >>>>> <a
moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
> > >>>><br>
> > >>>
_______________________________________________<br>
> > >>> Cerowrt-devel mailing list<br>
> > >>> <a moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> > >>> <a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
> > ><br>
> ><br>
> >
_______________________________________________<br>
> > Cerowrt-devel mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> > <a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
> ><br>
><br>
><br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>