Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads
Date: Sun, 5 Jan 2014 19:46:36 -0800	[thread overview]
Message-ID: <CAA93jw5HsgMw+Nt17ZnHJCt+HJqqoBGLPEFXBJJ2AVfcu0UdVw@mail.gmail.com> (raw)
In-Reply-To: <9628EA9A-E5AD-4D6B-A8E3-30AFECB2FC2E@gmx.de>

On Sat, Jan 4, 2014 at 12:22 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Rich,
>
> On Jan 4, 2014, at 19:16 , Rich Brown <richb.hanover@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)

Before: http://snapon.lab.bufferbloat.net/~cero2/taht_mahal/taht_house_comcast_long-3.svg

(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)

After:

http://snapon.lab.bufferbloat.net/~cero2/taht_mahal/fq_codel_30_8_taht_house_comcast-long.svg

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
value.

>> 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.
>
>         Agreed.

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
I appreciate
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).
>
> Best
>         Sebastian
>
>>
>> Rich
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

  reply	other threads:[~2014-01-06  3:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-04 18:16 Rich Brown
2014-01-04 18:40 ` Fred Stratton
2014-01-06  3:29   ` Dave Taht
2014-01-06  9:52     ` Fred Stratton
2014-01-06 14:12       ` Sebastian Moeller
2014-01-06 14:22         ` Fred Stratton
2014-01-06 14:27           ` Sebastian Moeller
2014-01-07 11:08             ` David Personette
2014-01-07 11:34               ` Sebastian Moeller
2014-01-07 12:11                 ` David Personette
2014-01-07 13:02                   ` Sebastian Moeller
2014-01-07 13:43                     ` David Personette
2014-01-07 14:53                       ` Fred Stratton
2014-01-06 10:56     ` Sebastian Moeller
2014-01-06 15:03       ` Dave Taht
2014-01-06 15:25         ` Sebastian Moeller
2014-01-04 20:22 ` Sebastian Moeller
2014-01-06  3:46   ` Dave Taht [this message]
2014-01-06 12:28     ` Sebastian Moeller
2014-01-05  9:04 ` Sebastian Moeller
2014-01-11 16:29 ` Rich Brown
2014-01-11 16:51   ` Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw5HsgMw+Nt17ZnHJCt+HJqqoBGLPEFXBJJ2AVfcu0UdVw@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox