[Cerowrt-devel] CeroWrt 3.10.18-1 Field Report

[Sebastian Moeller]

Hi Richard,


On Nov 12, 2013, at 18:26 , Richard E. Brown <richb.hanover at gmail.com> wrote:

>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>>>> - Had to enable and set AQM parameters, since they’re saved differently from the QoS settings in the 3.7.5-2 firmware. Set parameters to ~ 90% of link speeds 
>>> 
>>> 	Just curious, did you specify overhead and encapsulation?
> 
> No, I simply used the defaults on that page.

	Ah, you might want to try setting the link layer adaptation mechanism to tc_stab, the link layer to adls or atm and the overhead to 40 (or look at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to figure out the fixed per packet overhead of your link). This should allow you to specify a larger percentage of your link rate as shaped rate… But see the attached screenshot of my AQM tab



> 
>>>> - The kernel.log shows lots of the stack traces below: 2-5 per second on a long-term basis. 
>>> 
>>> 	These look quite weird, the error is a slow patch warning from hfsc_schedule_watchdog . But, hfsc is the queuing discipline used by stock OpenWrt, cerowrt , so far, has only used HTB (last I checked was cerowrt 3.10.11-3). So my guess is that you were running the default QOS system instead (or worse in addition) to cerowrt's. It would be great to see the output of:
>>> tc -d qdisc ; tc -s class show dev ifb0 ; tc -s class show dev ge00
>>> to check what is up with the AQM system...
>>> 
>>> Did you by any change use the QOS tab in 3.7.5-2 instead of running AQM or simple_qos.sh from rc.local/ifup? If so did you direct sys upgrade to keep the old configuration files?
> 
> Yes, I was using QoS in 3.7.5-2, and I kept the old configuration files (so I didn’t have to re-enter credentials for my DSL link, etc.) I guess it seems likely that I may have been running *both* (!)

	Probably just QOS, as I think both QOS and AQM start out by tearing down all discs… but the hfsc error should not affect AQM since it uses HTB.

> 
> Would a better upgrade path be to start with 3.7.5-2, then disable the QoS, then flash with 3.10.18-1? (My intuition tells me that this would remove the QoS settings from the loop…)

	Mhhh, I guess that should work.
> 
> It’s pretty easy to re-flash with 3.10.18-1 and run the tc commands. If disabling QoS makes sense, then after I do the ’tc’ experiment, I’ll re-flash with 3.7.5-2, turn off QoS, then reflash to 3.10.18-1.

	 This should not fix your PPPoE issues though… so maybe it is not the best time to switch…

> But it’ll have to wait ’til dark so no one else is using it. :-)

	Hihi, same issue on my side :) No "playing" with the network while my wife is using it 

Best
	Sebastian


> 
> Rich
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131112/404b9bc5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 167998 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131112/404b9bc5/attachment-0002.tiff>