[Cerowrt-devel] Final wording for CeroWrt SQM Pages (GUI and wiki)?

Wed Jan 22 14:18:38 EST 2014

Hi Rich, hi Dave,

On Jan 22, 2014, at 14:14 , Rich Brown <richb.hanover at gmail.com> wrote:

> Dave,
> 
> Thanks for this update. I think we're content with the behavior/performance of the current code. My note was just obsessing about the words that we present to customers who use CeroWrt.
> 
> On Jan 21, 2014, at 11:06 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 
>> On Tue, Jan 21, 2014 at 10:44 PM, Rich Brown <richb.hanover at gmail.com> wrote:
>>> OK, I think we have consensus. I have modified the text of the Setting up SQM page as described in the earlier messages (https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-January/001997.html) The wiki now says:  http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310
>>> 
>>> Next, the CeroWrt 3.10.26-2 GUI needs these changes:
>>> 
>>> - SQM tab heading needs to say "Smart Queue Management" instead of "Active Queue Management"
>> 
>> done in the comcast build and for future builds.
> 
> Great.
> 
>> Incidentally, part of the appeal of "SQM" to me is the first hit is
>> for a fertilizer company.
>> 
>> http://steve.savitzky.net/Songs/mushroom/
>> 
>> The song itself is kind of catchy (I don't know if he's online, I have
>> the CD) and can cause earworms on bad days.
>> 
>> "It comes from mushrooms, mushrooms, keep them in the dark..."
> 
> :-)
> 
>> I should also point out that multiple other schemes qualify as SQM in
>> my mind: gargoyle-router's ACC in particular, but also streamboost,
>> and qos-scripts, wondershaper, etc.
>> 
>> We could still use a brandname.
> 
> I added a bit of text for the motivation for changing to the SQM note. I can add a reference to Gargoyle-router, streamboost, qos-scripts. 
> 
> Wondershaper? :-)
> 
>>> - Change the text of the paragraph to say, "... and prioritization on a single interface."
>> 
>> Not sure where this goes. Current comcast code says:
>> 
>> m = Map("sqm", translate("Smart Queue Management"),
>>       translate("With <abbr title=\"Smart Queue
>> Management\">SQM</abbr> you " ..
>>               "can enable traffic shaping, better mixing (Fair Queueing)," ..
>>               " active queue length management (AQM) " ..
>>               " and prioritisation on one " ..
>>               "network interface."))
> 
> Sorry for being telegraphic. I had meant the sentence to be more explicit about the single interface. s/and prioritisation on one/and prioritisation on a single/
> 
>>> - Basic Settings tab: we had discussed removing the "Enable" checkbox and adding a "None" choice to the "Interface name" dropdown. Is this possible? (default setting should obviously be "ge00") If not, the tab is fine as-is.

	The interface list box is populated by a bit of code, not sure how easy it is to include none here.

>> 
>> Well this opens the problem of people wanting SQM on multiple
>> interfaces, which was a nice feature.
> 
> Ahah. When I looked at the GUI, I thought it would provide this facility only for the interface selected in the dropdown. Does the GUI handle it for multiple interfaces? (I know that people can edit their scripts for other interfaces.)

	Curently the GUI only allows to instantiate SQM on a single interface, but it used to be possible to configure more with the GUI (but since I never tested these I disabled that ability for the time being; reasoning if we expose this it should be tested).

> 
>>> - Queue Discipline tab is fine as-is.

	This probably will grow a few additional fields in the advanced or dangerous section, to expose limit and target and interval (for those qdiscs that support those). But this is not urgent...

>>> 
>>> - Link Layer Adaptation tab's dropdown lists three choices:
>>>       - None (default)
>>>       - ATM (almost every type of ADSL or DSL)
>> 
>> Is the () needed in the drop down
> 
> I like it for the "None (default)" case, and we've used (default) in other parts of the GUI. The ATM case is very wordy, though, but I figure it's easier for people to see that they have DSL and choose it (correctly).

	I see, I thought rather err on the verbose side here, but "ATM: for ADSL links" would do nicely. I would like to avoid DSL here as this typically encompasses ADSL, VDSL, and sometimes even SDSL, and we really only need this for all ADSLs and potentially a few VDSLs.

> 
>>>       - Ethernet with overhead
>> 
>> in (PPoe? pppoa? what?)
> 
> Yes, this is the bad case. What is technically true is "The choice that is not ATM, but allows you to enter some additional overhead" Unless someone has better wording, I say we stick with this until we find more people who fall into this category, at which point we'll know more about how to describe their situation.

	"Ethernet: for non-ATM links with additional overhead" this includes for example PPPoE overhead (seen on VDSL, and sometimes fiber), VLAN overhead (seen on VDSL and sometimes fiber), and what have you. Note PPPoA users need to select "ATM" instead as the oA stands for "over ATM". 

So to sum up is the following acceptable for all:
"None (default)"
"ATM: for ADSL links"
"Ethernet: non-ATM links with overhead"

Please let me know the what you all prefer and I check the consensus in (I really have lost track on what the current proposal was…)

Best Regards
	Sebastian

> 
>>> - Anything else?
>>> 
>>> It would be great to get these changes in the next build. Who can make those changes? Thanks.
>> 
>> I note I'm burnt and just lost a week I could ill afford to this. I
>> have pushed out all sources in the hope
>> someone else can update the build howto and get something that works....
> 
> As always, we appreciate everything you've done. I will be content if we can make these changes to the GUI so we can focus our brainpower on other matters. Safe travels.
> 
>> I am travelling this weekend and won't have time to get another build out.
>> 
>> Perhaps more cool stuff can land. I have a wishlist. :)
>> 
>> Perhaps someone can find a cure to the he problem but I fear it's
>> buried deep in a script or in ubus.
>> 
>>> Rich
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
>> 
>> 
>> -- 
>> Dave Täht
>> 
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel