From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4042221F0AE for ; Sun, 5 Jan 2014 19:46:38 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x13so15090056wgg.31 for ; Sun, 05 Jan 2014 19:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kMUsjIGNppElg/6OwlH63SVERlFgE4203V516yA6KS4=; b=cVvYfVG/s6wrtXS/dOoi80apA99JH0ghgl/iRxoAJrWFYIcH+uYllnl22/2lhKLV2j WwmxeeDG6lBrP7DdoXB+gHVF7E2uentCdT/T4iI++LqNUQyb3liFlyOafGByfpvmZ+yG V97ONv6Y4ZIQ6OUSY8/vc5Awp3lTeFY2DN6aAMFRzNSCbZYT00r4uKYlyqtFpJ+vIY1H Pb8MIwhIDnzcEhXCmj/mqH/k5HqsVzQDVLy7tHw4VrV08lhWtwdNRI+NwwoJ9z6YYlYW hujCmzDEJgMRgZpEnfN9uac4FJFmcRfTLAi0eBwB12n417ulowyfTpsYhBkbqVb/O4Ut 0Wcw== MIME-Version: 1.0 X-Received: by 10.180.105.199 with SMTP id go7mr10540870wib.53.1388979996348; Sun, 05 Jan 2014 19:46:36 -0800 (PST) Received: by 10.217.123.69 with HTTP; Sun, 5 Jan 2014 19:46:36 -0800 (PST) In-Reply-To: <9628EA9A-E5AD-4D6B-A8E3-30AFECB2FC2E@gmx.de> References: <01558084-B7D8-448A-A4ED-CE36D18AAA97@gmail.com> <9628EA9A-E5AD-4D6B-A8E3-30AFECB2FC2E@gmx.de> Date: Sun, 5 Jan 2014 19:46:36 -0800 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 03:46:44 -0000 On Sat, Jan 4, 2014 at 12:22 PM, Sebastian Moeller wrote: > Hi Rich, > > On Jan 4, 2014, at 19:16 , Rich Brown wrote: > >> QUESTION #5: I still don=92t have any great answers for the Link Layer A= daptation overhead descriptions and recommendations. In an earlier message,= (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/0= 01914.html and following messages), Fred Stratton described the overheads c= arried by various options, and Sebastian Moeller also gave some useful advi= ce. >> >> After looking at the options, I despair of giving people a clear recomme= ndation that would be optimal for their equipment. Consequently, I believe = the best we can do is come up with =93good enough=94 recommendations that a= re 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 measu= re the overhead on fast ADSL connection in Luxembourg and found that in thi= s double-play situation (television and internet via DSL) that an other wis= e 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 =93Setting up SQM=94 page= to reflect this understanding. See http://www.bufferbloat.net/projects/cer= owrt/wiki/Setting_up_AQM_for_CeroWrt_310 >> >> ADSL/ATM link: Choose =93ADSL/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 impressi= on that ADSL might still evolve to a different carrier, while ATM is basica= lly in maintenance mode (not much new deployment if any). > >> VDSL2 link: Choose =93VDSL=94, and set Per Packet Overhead to 8 > > There are several issues with this; VDSL is not the direct predec= essor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarit= ies 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 th= ink VDSL is not unlikely to be using an ATM link layer, VDSL2 is unlikely t= o do the same, both seem technically able to use ATM. > > >> Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed= ): Choose =93None (default)=94, and set Per Packet Overhead to 0 > > This is not going to be worse than today, so sounds fine (it woul= d be good to know whether there is truly no overhead on these links in prac= tical 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_comc= ast_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_hous= e_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 li= nk 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 =93ADSL/ATM=94 and the secon= d to =93VDSL=94 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 m= akes 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 figur= e 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 --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html