<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
IThe UK consensus fudge factor has always been 85 per cent of the
rate achieved, not 95 or 99 per cent.<br>
<br>
Devices express 2 values: the sync rate - or 'maximum rate
attainable' - and the dynamic value of 'current rate'.<br>
<br>
As the sync rate is fairly stable for any given installation - ADSL
or Fibre - this could be used as a starting value. decremented by
the traditional 15 per cent of 'overhead'. and the 85 per cent fudge
factor applied to that.<br>
<br>
Fibre - FTTC - connections can suffer quite large download speed
fluctuations over the 200 - 500 metre link to the MSAN. This
phenomenon is not confined to ADSL links.<br>
<br>
<br>
An alternative speed test is something like this<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<a href="http://download.bethere.co.uk/downloadMeter.html">http://download.bethere.co.uk/downloadMeter.html</a><br>
<br>
which, as Be has been bought by Sky, may not exist after the end of
April 2014.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<ul style="color: rgb(72, 72, 72); font-family: Verdana, sans-serif;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">
<li><em>[What is the proper description here?]</em><span
class="Apple-converted-space"> </span>If you use PPPoE (but
not over ADSL/DSL link), PPPoATM, or bridging that isn’t
Ethernet, you should choose<span class="Apple-converted-space"> </span><em>[what?]</em><span
class="Apple-converted-space"> </span>and set the Per-packet
Overhead to<span class="Apple-converted-space"> </span><em>[what?]</em></li>
</ul>
<p><br>
<em></em>For a PPPoA service, the PPPoA link is treated as PPPoE
on the second device, here running ceroWRT.<br>
</p>
<p>The packet overhead values are written in the dubious man page
for tc_stab. Sebastian has a potential alternative method of
formal calculation.<br>
</p>
<p>TYPICAL OVERHEADS<br>
The following values are typical for different adsl
scenarios (based on<br>
[1] and [2]):<br>
<br>
LLC based:<br>
PPPoA - 14 (PPP - 2, ATM - 12)<br>
PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly
FCS - 4+padding)<br>
Bridged - 32 (ATM - 18, ethernet 14, possibly FCS -
4+padding)<br>
IPoA - 16 (ATM - 16)<br>
<br>
VC Mux based:<br>
PPPoA - 10 (PPP - 2, ATM - 8)<br>
PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly
FCS - 4+padding)<br>
Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS -
4+padding)<br>
IPoA - 8 (ATM - 8)</p>
<p><br>
For VC Mux based PPPoA, I am currently using an overhead of 18 for
the PPPoE setting in ceroWRT.<br>
</p>
<p><br>
Were I to use a single directly connected gateway, I would input a
suitable value for PPPoA in that openWRT firmware. In theory, I
might need to use a negative value, bmt the current kernel does
not support that.<br>
</p>
<p>I have used many different arbitrary values for overhead. All
appear to have little effect.<br>
</p>
<p>As I understand it, the current recommendation is to use tc_stab
in preference to htb_private. I do not know the basis for this
value judgement.<br>
</p>
<p><br>
</p>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 28/12/13 10:01, Sebastian Moeller
wrote:<br>
</div>
<blockquote cite="mid:F4E0057B-EBAC-43CF-9BC1-6D44B697264B@gmx.de"
type="cite">
<pre wrap="">Hi Rich,
great! A few comments:
Basic Settings:
[Is 95% the right fudge factor?] I think that ideally, if we get can precisely measure the useable link rate even 99% of that should work out well, to keep the queue in our device. I assume that due to the difficulties in measuring and accounting for the link properties as link layer and overhead people typically rely on setting the shaped rate a bit lower than required to stochastically/empirically account for the link properties. I predict that if we get a correct description of the link properties to the shaper we should be fine with 95% shaping. Note though, it is not trivial on an adel link to get the actually useable bit rate from the modem so 95% of what can be deduced from the modem or the ISP's invoice might be a decent proxy…
[Do we have a recommendation for an easy way to tell if it's working? Perhaps a link to a new Quick Test for Bufferbloat page. ] The linked page looks like a decent probe for buffer bloat.
</pre>
<blockquote type="cite">
<pre wrap="">Basic Settings - the details...
CeroWrt is designed to manage the queues of packets waiting to be sent across the slowest (bottleneck) link, which is usually your connection to the Internet.
</pre>
</blockquote>
<pre wrap="">
I think we can only actually control the first link to the ISP, which often happens to be the bottleneck. At a typical DSLAM (xDSL head end station) the cumulative sold bandwidth to the customers is larger than the back bone connection (which is called over-subscription and is almost guaranteed to be the case in every DSLAM) which typically is not a problem, as typically people do not use their internet that much. My point being we can not really control congestion in the DSLAM's uplink (as we have no idea what the reserved rate per customer is in the worst case, if there is any).
</pre>
<blockquote type="cite">
<pre wrap="">CeroWrt can automatically adapt to network conditions to improve the delay/latency of data without any settings.
</pre>
</blockquote>
<pre wrap="">
Does this describe the default fq_codels on each interface (except fib?)?
</pre>
<blockquote type="cite">
<pre wrap="">However, it can do a better job if it knows more about the actual link speeds available. You can adjust this setting by entering link speeds that are a few percent below the actual speeds.
Note: it can be difficult to get an accurate measurement of the link speeds. The speed advertised by your provider is a starting point, but your experience often won't meet their published specs. You can also use a speed test program or web site like <a class="moz-txt-link-freetext" href="http://speedtest.net">http://speedtest.net</a> to estimate actual operating speeds.
</pre>
</blockquote>
<pre wrap="">
While this approach is commonly recommended on the internet, I do not believe that it is that useful. Between a user and the speediest site there are a number of potential congestion points that can affect (reduce) the throughput, like bad peering. Now that said the sppedtets will report something <= the actual link speed and hence be conservative (interactivity stays great at 90% of link rate as well as 80% so underestimating the bandwidth within reason does not affect the latency gains from traffic shaping it just sacrifices a bit more bandwidth; and given the difficulty to actually measure the actually attainable bandwidth might have been effectively a decent recommendation even though the theory of it seems flawed)
</pre>
<blockquote type="cite">
<pre wrap="">Be sure to make your measurement when network is quiet, and others in your home aren’t generating traffic.
</pre>
</blockquote>
<pre wrap="">
This is great advise.
I would love to comment further, but after reloading <a class="moz-txt-link-freetext" href="http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310">http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310</a> just returns a blank page and I can not get back to the page as of yesterday evening… I will have a look later to see whether the page resurfaces…
Best
Sebastian
On Dec 27, 2013, at 23:09 , Rich Brown <a class="moz-txt-link-rfc2396E" href="mailto:richb.hanover@gmail.com"><richb.hanover@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">You are a very good writer and I am on a tablet.
</pre>
</blockquote>
<pre wrap="">Thanks!
</pre>
<blockquote type="cite">
<pre wrap="">Ill take a pass at the wiki tomorrow.
The shaper does up and down was my first thought...
</pre>
</blockquote>
<pre wrap="">Everyone else… Don’t let Dave hog all the fun! Read the tech note and give feedback!
Rich
</pre>
<blockquote type="cite">
<pre wrap="">On Dec 27, 2013 10:48 AM, "Rich Brown" <a class="moz-txt-link-rfc2396E" href="mailto:richb.hanover@gmail.com"><richb.hanover@gmail.com></a> wrote:
I updated the page to reflect the 3.10.24-8 build, and its new GUI pages.
<a class="moz-txt-link-freetext" href="http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310">http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310</a>
There are still lots of open questions. Comments, please.
Rich
_______________________________________________
Cerowrt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Cerowrt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Cerowrt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>