Hi Sebastian, Fred, Toke,
Thanks for all these comments about the AQM GUI. It feels to me that we’re
working on an interesting (GUI) design challenge along with all the technical
wrassling that’s going on:
- Are we leaving enough knobs and levers exposed so that people can easily help
us with research into the best settings?
- Are we aiming toward a set of default parameters that people can set and
forget?
I suspect that the answer to both is “yes”, but the real question we’re talking
about now is *when* we do each. My vote:
- For now, leave more knobs and levers exposed. If we do this...
- We need to provide guidance for these settings. I am not (yet) sufficiently
familiar with the issues to make these judgements/decisions on my own.
- I never want to see paragraphs of text in a GUI. That simply implies that the
GUI needs to link to a page on the wiki with our collective wisdom on the
subject. I’ll help with that.
Best,
Rich
On Dec 15, 2013, at 6:33 AM, Sebastian Moeller <moell...@gmx.de> wrote:
> Hi Rich,
>
>
> On Dec 15, 2013, at 06:16 , Rich Brown <richb.hano...@gmail.com> wrote:
>
>> I did a tftp install of CeroWrt 3.10.42-1 on my secondary WNDR3800. I then
>> used the “secondary” script to reconfigure the subnets and SSIDs to be
>> different from my primary CeroWrt router. I know that a lot of things are
>> still in flux, but I thought I should comment that I noticed the following:
>>
>> 0) It seems to work mostly. I could connect my MacBook on Ethernet, but not
>> wireless (see below) I ran RRUL with reasonable results (I think)
>>
>> 1) Only the ge00 interface was in its proper firewall zone (wan); I used the
>> GUI to move all the gwxx to guest and se00 and swxx interfaces to lan.
>>
>> 2) None of the wireless SSIDs (2.4 or 5 GHz) allowed connections. It appears
>> that they’re there, my MacBook sees them, but it cannot get an address for
>> itself on those SSIDs.
>>
>> 3) Clicking the AQM tab gave the following diagnostic info:
>>
>> /usr/lib/lua/luci/dispatcher.lua:448: Failed to execute cbi dispatcher
>> target for entry '/admin/network/aqm'.
>> The called action terminated with an exception:
>> /usr/lib/lua/luci/model/cbi/aqm.lua:63: attempt to index global 'sc' (a nil
>> value)
>> stack traceback:
>> [C]: in function 'assert'
>> /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
>> /usr/lib/lua/luci/dispatcher.lua:195: in function
>> </usr/lib/lua/luci/dispatcher.lua:194>
>>
>> 3a) To work around this (as noted in another message on the list), remove
>> leading “s” of line 63 of /usr/lib/lua/luci/model/cbi/aqm.lua to read:
>>
>> c:depends("advanced", "1”)
>
> Sorry for that, I committed an untested change (adding two lines, how
> much can go wrong?) and forgot to edit the 2nd copy...
>
>>
>> 4) In the AQM tab, I’m not sure which linklayer adaptation mechanism to use.
>
> If you have DSL either is good. In case you work with jumbo packets on
> ge00 or use GSO you should use htb_private, otherwise both are fine. (I will
> try to get patches for tc_stab into the kernel that makes this difference
> moot ad might alls us to consolidate on the generic tc_stab). I will add this
> information onto the GUI. (Since there are only few users for the link layer
> adjustments, both methods are somewhat prone to bitrott, so I think it has
> value to expose both so that we can cross test both, assuming both will not
> go bad at the same kernel revision...)
>
>
>> It would be good to have a concise summary of the proper settings for
>> various use cases.
>
> Well, yes it would, unfortunately it is slightly tricky to do so. Dave
> proposed a redesign of the AQM GUI page with tabs for the different
> functional pieces. When I prototype this I will try to include more
> information about properly selecting those values. That said typically mpu
> shopule be zero, tcMTU should be 2047 (as the interface MTU will be around
> 1500), tsize should be 128. Overhead is the trickiest as it depends on the
> actual encapsulation used on your link. If I am correct the maximum for this
> is 44 and a typical value is 40, so we could default to 44 to do no damage
> but we would waste bandwidth for almost everybody. What do you think about
> including links in the GUI so the user can go and read up on this? (I would
> recommend http://www.faqs.org/rfcs/rfc2684.html and
> http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ but both are not that
> easy to digest...)
>
>> (And to install a set of defaults that will “do the right thing” for the
>> majority of people, so we don’t have to explain it very often.)
>
> Okay, realistically the most important thing is to select one of the
> mechanisms to account for the link layer if you are on ATM based DSL, so
> typically ADSL1, ADSL2, ADSL2+ (with an off chance with VDSL1), assuming a
> typical link the link MTU will be ~1500 so the defaults for tcMTU tsize and
> MPU will work fine. We could set the default link layer to ADSL and the
> default overhead to 40 if Dave agrees, to preconfigure a reasonable default…
> I have been thinking about how to detect the link layer quantization
> and the protocol overhead automatically, but so far do not have anything
> useful to include with cerowrt (on a fast link one needs to measure all night
> to get small enough deviations to reliably detect the quantisation). If you
> are willing to play guinea pig I will send you the measurement script...
>
>
>>
>> 5) I did *not* try the Hurricane Electric 6in4 tunnel.
>>
>> Best regards,
>>
>> Rich Brown
>> Hanover, NH
>> _______________________________________________
>> 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
