[Cerowrt-devel] Final wording for CeroWrt SQM Pages (GUI and wiki)?
richb.hanover at gmail.com
Wed Jan 22 08:14:01 EST 2014
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.
> Incidentally, part of the appeal of "SQM" to me is the first hit is
> for a fertilizer company.
> 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.
>> - 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.
> 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.)
>> - Queue Discipline tab is fine as-is.
>> - 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).
>> - 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.
>> - 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.
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
> Dave Täht
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel