Hi Rich,
On Dec 28, 2013, at 15:27 , Rich Brown <[email protected]> wrote:
Hi Sebastian,
I would love to comment further, but after reloading
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
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…
I’m not sure what happened to this page for you. It’s available now (at least
to me) at that URL…
Well, it is back for me as well,
Rich
So without much further ado...
Queueing Discipline - the details...
CeroWrt is the proof-of-concept for the CoDel and fq_codel algorithms that
prevent large flows of data (downloads, videos, etc.) from affecting
applications that use a small number of small packets. The default of fq_codel
and the simple.qos script work very well for most people.
[What are the major features of the simple.qos, simplest.qos, and drr.qos
scripts?]
simple.qos, has a shaper and three classes with different priorities
simplest.qos has a shaper and just one class for all traffic
drr.qos, no idea yet, I have not tested it nor looked at it closely
Explicit Congestion Notification (ECN) is a mechanism for notifying a sender
that its packets are encountering congestion and that the sender should slow
its packet delivery rate. We recommend that you turn ECN off for the Upload
(outbound, egress) direction, because fq_codel handles and drops packets before
the bottleneck, providing the congestion signal to local senders.
Well, we recommend to disable egress ECN as marked packets still need
to go over the slow bottleneck link. Dropping these instead frees up the egress
queue and will allow faster reactivity on the slow uplink. With a slow enough
uplink, every packet counts...
For the Download (inbound, ingress) link, we recommend you turn ECN on so that
CeroWrt can inform the remote sender that it has detected congestion.
The same signaling is achieved by dropping the packet and not sending
an ACK packet for that data, but this takes a bit longer as it relays on some
timer in the sender.
[Is this still relevant? Arriving packets have already cleared the
bottleneck, and hence dropping has no bandwidth advantage anymore. ]
I think it still is relevant.
If you make your own queue setup script, you can pass parameters to them using the
"Dangerous Configuration" strings. The name forewarns you.
Well the dangerous string is just appended to the tc command that sets up the
queuing disciplines, so you can use this to modify the existing invocation, say by
changing values away from implicit defaults. Like in Fred's case where he added
"target 25ms" in the egress string to change the target from the 5ms default.
3. Link Layer Adaptation
You must set the Link Layer Adaptation options correctly so that CeroWrt can
perform its best with VoIP, gaming, and other protocols that rely on short
packets. The general rule for selecting the Link Layer Adaption is:
• If you use any kind of DSL/ADSL connection to the Internet (that is, if you get
your internet service through the telephone line), you should choose the "ATM"
item.
ADSL is the keyword here, people on VDSL most likely will not need to
set ATM, but ethernet.
Leave the Per-packet Overhead set to zero.
I know I am quite wobbly on this topic, but we should recommend to use
40 as default here if ATM was selected.
• [What is the proper description here?] If you use PPPoE (but not over
ADSL/DSL link)
You will have at least 8 byte overhead, probably more. Unfortunatelly I
have no idea how to measure the overhead on non-ATM links.
, PPPoATM, or bridging that isn’t Ethernet, you should choose [what?] and set
the Per-packet Overhead to [what?]
I have to pass, maybe someone with such a link can chime in here? Then
again these setups should be rare enough to just punt (we could let the users
know they are on their own and ask for the conclusion they reached to
incorporate into the wiki).
• If you use Ethernet, Cable modem, Fiber, or other kind of connection
to the Internet, you should choose “none (default)”.
The decision tree should be, you have no ATM carrier and you do not
know of any per packet overhead you should select none.
If you cannot tell what kind of link you have, first try the ATM choice and run
the Quick Test for Bufferbloat. If the results are good, you’re done.
This will not really work, on non-ATM links selecting ATM will
overestimate the wire size of packets thereby retaining excellent latency even
at high nominal shaped ratios (should even work well at 105% of link capacity).
To really test for this we need a test that measures the link capacity for
different packet sizes, but I digress.
You can also try the other link layer adaptations to see which performs better.
So for a real ATM link selecting link layer ATM should allow to specify
higher shaping percentage than 90% for large and 85% for small packets.
Link Layer Adaptation - the details…
It is especially important to set this on links that use ATM framing (almost
all DSL/ADSL links do), because ATM adds five additional bytes of overhead to a
48-byte frame. Unless you tell CeroWrt to account for the ATM framing bytes,
short packets will appear to take longer to send than expected, and CeroWrt
will penalize that traffic.
CeroWrt can also account for the overhead imposed by PPPoE, PPPoATM and other
links when you select that option.
Besides the nasty 48 in 53 issue, each packet also carries some ATM
header overhead, just exactly how much depends on the actual encapsulation used
(Fred send a useful short list of the different encapsulations).
Ethernet, Cable Modems, Fiber generally do not need any kind of link layer
adaptation.
The "Advanced Link Layer" choices are relevant if you are sending packets
larger than 1500 bytes (this is unusual for most home setups.)
Actually the defaults will be good up to 2048 byte packets (including
overhead) so even baby jumbo frames are covered :)
[What to say about the options on the maximal size, number of entries, and
minimal packet size?]
I would give a link to the tc stab man page, we just expose the values
to be passed to stab here. I really assume there is nothing that needs changing
in here unless the user knows exactly why he wants a change.
[What to say about tc_stab vs htb_private?]
Basically, unless you know better, stick to tc_stab.
Best Regards
Sebastian
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
