Hi Fred,
thanks to your input.
On Dec 15, 2013, at 12:55 , Fred Stratton <fredstrat...@imap.cc> wrote:
> Over the last 30 years, graphical interfaces have been bloated with pages of
> explanatory text.
>
> If more explanation of the interface is required, it could be incorporated in
> the wiki. Links could also be incorporated in the wiki.
So, I think it would be nice if the GUI contains enough information for
a typical user to set up the system and forget about it. Alas, the ATM
encapsulation is a bit complicated and arcane, so a bit of explanation seems
required. What does the rest of you think: keep the GUI clean or include a bit
background information?
>
> I suggest the AQM lua interface is kept simple and therefore easier to
> maintain.
I hope that there is not much maintenance necessary once all features
are supported. At least I the ATM encapsulation issues, hopefully, are
constant and will not change in the future… (except, I dream, they will become
obsolete once ATM goes the way of the Dodo…).
But, hey, so far we have one voice for more detail/instructions and one
for terseness.
As said before, I will still try to rearrange the AQM single tab into a
collection of tabs, that should allow to include a bit more help, hopefully
without sacrificing simplicity too much; so in the end both Rich and Fred might
find it acceptable. (It just means that we will have to choose the terse help
text very carefully; help would be greatly appreciated)
Best
Sebastian
>
>
> On 15/12/13 11:33, Sebastian Moeller 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
>
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
