[Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads
dave.taht at gmail.com
Sun Jan 5 22:46:36 EST 2014
On Sat, Jan 4, 2014 at 12:22 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Rich,
> On Jan 4, 2014, at 19:16 , Rich Brown <richb.hanover at gmail.com> 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.
> Not wanting to be a spoilsport, but IMHO the issue is complicated hence no simple recommendations. I know that my last word was that 40bytes would be a good default overhead, but today I had the opportunity to measure the overhead on fast ADSL connection in Luxembourg and found that in this double-play situation (television and internet via DSL) that an other wise invisible VLAN was further increasing the overhead (from the 40 expected to 44 bytes). At least on faster links these combo packets (internet, phone and potentially telephone) are becoming more and more common, so maybe the recommendation should be 44 (hopping that FCS are truly rare).
>> 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
> While I prefer ATM, I think all deployed ADSL is on ATM so these are synonyms for our purpose. I prefer ATM since the most critical part of the link layer adjustments is caused by the impedance mismatch between what ATM offers and what the data transport layer requires. I have the impression that ADSL might still evolve to a different carrier, while ATM is basically in maintenance mode (not much new deployment if any).
>> VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
> There are several issues with this; VDSL is not the direct predecessor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave the same. From my cursory reading of the standards of both I think VDSL is not unlikely to be using an ATM link layer, VDSL2 is unlikely to do the same, both seem technically able to use ATM.
>> Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0
> This is not going to be worse than today, so sounds fine (it would be good to know whether there is truly no overhead on these links in practical useage).
Well, I just spent a painful hour trying to find an optimum for the
device on my mom's (cable) network, which I plan to replace with one
that is ipv6 compatible shortly. (I am settled in one place for a
while, so may setup a local dhcpv6-pd server, too - but my primary
mission is to get a test suite going)
(note it took a long time to fully saturate the buffers as the test
box was 50ms away. I usually test with one 16ms away)
The upload value isn't making that much sense, and I lost a lot of
throughput. Variety of other tests in that dir.
> Quick vote: anyone on this list using ceroWRT on an VDSL/VDSL2 link or cable fiber whatnot that could do some quick testing for us?
There doesn't appear to be any need for "overhead" related settings on
cable. There might be some use on docsis 3 in changing the htb burst
>> NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description.
> I am fine with changing names, just see what the consensus is for the names.
I can live with whatever is decided here, and sebastian has commit access.
>> 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.
Go for it!
>> As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.
I don't mind if cero stays too complex for mom to configure, although
the efforts to simplify things.
> I guess, we need a new wiki page detailing the procedure to figure out the link layer (and overhead if on ATM).
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel