[Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

+ hopefully nasty interface initialization bug fixed
http://www.bufferbloat.net/issues/437
+ dnsmasq 2.68
+ pie v4
+ latest AQM & AQM GUI code
+ TSQ fix (part of 3.10.24)
+ package signing enabled by default

- I can get a DMA tx error out of it
- untested as a final set of commits because I've been at it all day
and I turn into a pumpkin at midnight
- I still haven't looked at the mount-utils bug (does it mount ext4?
btrfs? do fsck without that package?)

While I'm at it, my current patchset compiled for x86_64 for 3.12.5
for ubuntu 13.10 is here:

http://snapon.lab.bufferbloat.net/~d/deb/

The delta from mainline linux is increasingly small.

along with the builds I have in the lab. I am hoping to push this out
to all of the yurtlab in preparation for a major batch of tests
against some new devices, and hoping the lousy benchmarks I got
earlier today was merely the TSQ regression.


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

ok, I did some minimalistic testing, the bringing up the interfaces
bug appears to be dead. (thx everyone!) can't test the gui from where
I am, aqm-scripts didn't go boom, will start some overnight stress
tests of the wifi

I am going to make some ipv6 tunnels to the lab now that I have not
been spending enough time there. It got really chilly this month! But
first up is having a release stable enough to do that with...

bedtime for buggo, happy testing

On Sun, Dec 15, 2013 at 11:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
> + hopefully nasty interface initialization bug fixed
> http://www.bufferbloat.net/issues/437
> + dnsmasq 2.68
> + pie v4
> + latest AQM & AQM GUI code
> + TSQ fix (part of 3.10.24)
> + package signing enabled by default
>
> - I can get a DMA tx error out of it
> - untested as a final set of commits because I've been at it all day
> and I turn into a pumpkin at midnight
> - I still haven't looked at the mount-utils bug (does it mount ext4?
> btrfs? do fsck without that package?)
>
> While I'm at it, my current patchset compiled for x86_64 for 3.12.5
> for ubuntu 13.10 is here:
>
> http://snapon.lab.bufferbloat.net/~d/deb/
>
> The delta from mainline linux is increasingly small.
>
> along with the builds I have in the lab. I am hoping to push this out
> to all of the yurtlab in preparation for a major batch of tests
> against some new devices, and hoping the lousy benchmarks I got
> earlier today was merely the TSQ regression.
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Rich Brown]

Dave, List,

> + hopefully nasty interface initialization bug fixed
> http://www.bufferbloat.net/issues/437

In a one-out-of-one test, this build causes all six wireless interfaces to start up: CEROwrt (and guest) on 2.4 and 5 GHz, and both babel SSID’s.

In addition, the ‘wifi’ command does not give any diagnostic output as I had mentioned in my earlier message.

Keepin’ my fingers crossed.

Rich

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Rich,


On Dec 16, 2013, at 14:45 , Rich Brown <richb.hanover@gmail.com> wrote:

> Dave, List,
> 
>> + hopefully nasty interface initialization bug fixed
>> http://www.bufferbloat.net/issues/437
> 
> In a one-out-of-one test, this build causes all six wireless interfaces to start up: CEROwrt (and guest) on 2.4 and 5 GHz, and both babel SSID’s.
> 
> In addition, the ‘wifi’ command does not give any diagnostic output as I had mentioned in my earlier message.
> 
> Keepin’ my fingers crossed.

	That sounds quite promising. I would be delighted, if stability permits, if you could test the current AQM implementation and send me your feedback and or open questions. It seems I have been looking at the link layer issue for so long that I do not realize which information is required so please let me know if parts are to terse or too verbose.

Best Regards
	sebastian

> 
> Rich
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 4150 bytes --]

Sebastian, List,

> 	That sounds quite promising. I would be delighted, if stability permits, if you could test the current AQM implementation and send me your feedback and or open questions. It seems I have been looking at the link layer issue for so long that I do not realize which information is required so please let me know if parts are to terse or too verbose.

Thanks for making these changes. I was able to check the appearance (but not the performance) of the new GUI. My thoughts/comments/questions inserted between the screen shots:



The Basic Settings tab looks good. It’s all stuff I understand. I might like a More Info: link that tells me what the parameters are, and how I should set them. This is especially important because there’s a trick you need to know - set them to 85-90% of the link’s actual bandwidth. 

The introductory text could also read, “With AQM you can enable traffic shaping and prioritisation on a *single* network interface, your uplink to the Internet. Once you set the download and upload speeds (below), most people can leave the other options set to their defaults.” (at least, if that’s true…)



It looks a little funny with just the bare un-checked box. But I’m not horrified: checking the box shows the screen below, which is certainly clear enough.



- I like how fq_codel is labeled “default”. Since the other two controls are labeled with “default, should we do the same with the queue setup script (“simples.qos (default)”)?

- Do we include pfifo anymore? (just to see how bad things could be?)

- Should we tell which version of pie has been included? (I’ve heard the names piev3 and piev4)

- In the Basic tab, we talk about download/upload. In the ECN settings, we talk about inbound/outbound. Should we choose one pair of terms for consistency (perhaps, “ECN on downloaded/uploaded packets”?)



This tab forces us to confront all the sticky questions. The first question immediately makes me wonder, “Do I have DSL or ATM? Or both? What’s a ‘tc_stab'? How do I know?” And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL; and where ethernet fits into the scheme of things. 

It would be cool to set everything here automagically. Nonetheless, this is still a research project, and we probably don’t know enough to do that. Consequently, we should strive for good defaults that people can override while making experiments or if the defaults are wrong. I don’t know any answers here, or even where I’m going with this, but I’ll observe the following:

- (I believe) The Link Layer Adaptations help the router squeeze out the maximum performance accounting for peculiar link's transmission/framing method. If this stuff isn't set optimally, things will still work, at a (small?) loss of performance.

- The choices in the Protocol dropdown for the GE00 interface are:

Static address
DHCP client
Unmanaged
Dual-Stack Lite (RFC6333)
IPv6-in-IPv4 (RFC4213)
IPv6-over-IPv4 (6to4)
IPv6-over-IPv4 (6rd)
DHCPv6 client
PPP
PPtP
PPPoE
PPPoATM
UMTS/GPRS/EV-DO
L2TP

- (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) 

- For each of those link layers, what customizations are required? Can we give guidance (on the wiki) for people who want to set them? (Although it would be slick if someone chose the PPPoE protocol, and this tab got set up properly, we may not know enough today to do this properly.) 

Fussy GUI comments:

- Would it be correct to change the label to say, “Show Advanced Link Layer Options, (only needed if using large packets, MTU > 1500 bytes)”

- The “Which linklayer adaptation …” question runs outside its bounding box in the GUI. This only happens when I make the window narrow for the screen shot, so it probably isn’t worth perseverating about.

- I would be tempted make “Link Layer” two words in the GUI, unless it’s a term of art.

Thanks, all, for this good work!

Rich

[-- Attachment #2.1: Type: text/html, Size: 5678 bytes --]

[-- Attachment #2.2: PastedGraphic-1.png --]
[-- Type: image/png, Size: 88299 bytes --]

[-- Attachment #2.3: PastedGraphic-4.png --]
[-- Type: image/png, Size: 75746 bytes --]

[-- Attachment #2.4: PastedGraphic-2.png --]
[-- Type: image/png, Size: 128059 bytes --]

[-- Attachment #2.5: PastedGraphic-3.png --]
[-- Type: image/png, Size: 123847 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 8294 bytes --]

Hi Rich,

thanks for your time and input.


On Dec 17, 2013, at 04:45 , Rich Brown <richb.hanover@gmail.com> wrote:

> Sebastian, List,
> 
>> 	That sounds quite promising. I would be delighted, if stability permits, if you could test the current AQM implementation and send me your feedback and or open questions. It seems I have been looking at the link layer issue for so long that I do not realize which information is required so please let me know if parts are to terse or too verbose.
> 
> Thanks for making these changes. I was able to check the appearance (but not the performance) of the new GUI. My thoughts/comments/questions inserted between the screen shots:
> 
> 
> 
> The Basic Settings tab looks good. It’s all stuff I understand. I might like a More Info: link that tells me what the parameters are, and how I should set them. This is especially important because there’s a trick you need to know - set them to 85-90% of the link’s actual bandwidth. 
> 
> The introductory text could also read, “With AQM you can enable traffic shaping and prioritisation on a *single* network interface, your uplink to the Internet. Once you set the download and upload speeds (below), most people can leave the other options set to their defaults.” (at least, if that’s true…)
> 
> 
> 
> It looks a little funny with just the bare un-checked box. But I’m not horrified: checking the box shows the screen below, which is certainly clear enough.
	
	Okay, I think I will expose the disc and script selection unconditionally and only put the ECN under the advanced configuration checkbox.

> 
> 
> 
> - I like how fq_codel is labeled “default”. Since the other two controls are labeled with “default, should we do the same with the queue setup script (“simples.qos (default)”)?

	I will have a look, de to the implementation that is not as easy as one would like (the GUI displays all scripts it finds in /usr/lib/aqm, which makes adding new scripts a breeze but puts some restrictions on what is displayed in the GUI)

> 
> - Do we include pfifo anymore? (just to see how bad things could be?)

	Dave?

> 
> - Should we tell which version of pie has been included? (I’ve heard the names piev3 and piev4)

	Since we will not have concurrent PIEversions that have the same name I vote for leaving the version information out of the GUI, otherwise we have to keep updating the GUI...

> 
> - In the Basic tab, we talk about download/upload. In the ECN settings, we talk about inbound/outbound. Should we choose one pair of terms for consistency (perhaps, “ECN on downloaded/uploaded packets”?)

	Good point. I will harmonize the nomenclature

> 
> 
> 
> This tab forces us to confront all the sticky questions. The first question immediately makes me wonder, “Do I have DSL or ATM?

	The ida was that unless you have DSL or ATM you probably do not care. In most cases DSL means ATM carrier (and it is only the last that is relevant, but also users typically do not have this information, so asking for adel is sort of a proxy)

> Or both? What’s a ‘tc_stab'? How do I know?”

	Yeah, I guess td-stab needs a better name… "Perform link layer adjustments: Yes / No"

> And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL;

	No ADLS is one out of a family of xDSLs (digital subscriber lines). As far as I know SDSL does not use ATM, VDSL1 might use ATM and all ADSL variants use ATM.

> and where ethernet fits into the scheme of things.

	Ethernet is also a link layer, one that does typically not show quantization as ATM does, selecting the ethernet link layer allows to still specify an overhead, and that is somewhat useful for VDSL (since VDSL often still uses PPPoE).

>  
> 
> It would be cool to set everything here automagically.

	Yes it would, and no I do not see this coming, as only the ISP has all the required information readily available, end-users typically do not. Trying to figure it out empirically takes too long, especially at higher link speeds.

> Nonetheless, this is still a research project, and we probably don’t know enough to do that. Consequently, we should strive for good defaults that people can override while making experiments or if the defaults are wrong. I don’t know any answers here, or even where I’m going with this, but I’ll observe the following:
> 
> - (I believe) The Link Layer Adaptations help the router squeeze out the maximum performance accounting for peculiar link's transmission/framing method. If this stuff isn't set optimally, things will still work, at a (small?) loss of performance.

	Okay, bear with me here; the telco's created ATM as a carrier for digital voice data, they wanted small packets to allow good multiplexing behavior (and I think france wanted 32byte payload packets to be able to avoid having to do echo cancelation in their network, while the US having to do echo cancelation due to the extent of the country wanted 64 bytes payload; hence a compromise on 48 bytes payload). ATM cells as they are called typical require a 5 bytes header for 48 bytes of payload. So far all is well and one could say just take the link rate * 48 / 53 to get the "payload rate" and set the shaper to this; problem solved. BUT alas, ATM will always put each packet into an integer number of cells, or put differently will pad the last cell. So consider a very small UDP packet that with header (and overhead) has say 48 bytes all is well that just takes one ATM cell on the wire and all is fine, but add one more byte. Now we have to send two full ATM cells taking 96 bytes. In other words the atm carrier quantization can effectively double the effective size of a packet. So either we shape down to 50% to always have enough bandwidth even for the worst encapsulation or we actually calculate the wire size of each packet to send and use this size to calculate how long the link will be "blocked" while sending this packet (and this is what the link layer adaptation actually does). 
	So in short if your traffic has lots of small packets (say VoIP) it is affected most severely by the quantization and will expose buffer bloat if cerowrt does not shape properly.

> 
> - The choices in the Protocol dropdown for the GE00 interface are:
> 
> Static address
> DHCP client
> Unmanaged
> Dual-Stack Lite (RFC6333)
> IPv6-in-IPv4 (RFC4213)
> IPv6-over-IPv4 (6to4)
> IPv6-over-IPv4 (6rd)
> DHCPv6 client
> PPP
> PPtP
> PPPoE
> PPPoATM
> UMTS/GPRS/EV-DO
> L2TP
> 
> - (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) 

	Well for PPPoATM I agree, but PPPoE is also used with VDSL which uses PTM in stead of ATM and has no quantization issues, but still profits from setting the overhead correctly so needs the link layer adaptation as well. Now, as far as I know PPPoATM is quite rare so I have no idea of how to deal with the common case automagically.

> 
> - For each of those link layers, what customizations are required?

	Hopefully just the overhead and the type of the link layer.

> Can we give guidance (on the wiki) for people who want to set them? (Although it would be slick if someone chose the PPPoE protocol, and this tab got set up properly, we may not know enough today to do this properly.) 

	You are right, there are four possible overhead values for PPPoE ranging from 32 to 44 bytes and two possible link layers, so that in itself is not too helpful.

> 
> Fussy GUI comments:
> 
> - Would it be correct to change the label to say, “Show Advanced Link Layer Options, (only needed if using large packets, MTU > 1500 bytes)”

	

> 
> - The “Which linklayer adaptation …” question runs outside its bounding box in the GUI. This only happens when I make the window narrow for the screen shot, so it probably isn’t worth perseverating about.
> 
> - I would be tempted make “Link Layer” two words in the GUI, unless it’s a term of art.

	I am fine with that, so unless some one objects I will switch to "link layer"

> 
> Thanks, all, for this good work!
> 
> Rich


[-- Attachment #2.1: Type: text/html, Size: 14032 bytes --]

[-- Attachment #2.2: PastedGraphic-1.png --]
[-- Type: image/png, Size: 88299 bytes --]

[-- Attachment #2.3: PastedGraphic-4.png --]
[-- Type: image/png, Size: 75746 bytes --]

[-- Attachment #2.4: PastedGraphic-2.png --]
[-- Type: image/png, Size: 128059 bytes --]

[-- Attachment #2.5: PastedGraphic-3.png --]
[-- Type: image/png, Size: 123847 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]

Hi Sebastian,

>> And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL;
> 
> 	No ADLS is one out of a family of xDSLs (digital subscriber lines). As far as I know SDSL does not use ATM, VDSL1 might use ATM and all ADSL variants use ATM.
> 
>> and where ethernet fits into the scheme of things.
> 
> 	Ethernet is also a link layer, one that does typically not show quantization as ATM does, selecting the ethernet link layer allows to still specify an overhead, and that is somewhat useful for VDSL (since VDSL often still uses PPPoE).

... and ...

>> - (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) 
> 
> 	Well for PPPoATM I agree, but PPPoE is also used with VDSL which uses PTM in stead of ATM and has no quantization issues, but still profits from setting the overhead correctly so needs the link layer adaptation as well. Now, as far as I know PPPoATM is quite rare so I have no idea of how to deal with the common case automagically.

So basically, if I understand what you’re saying, it’s a big mess. :-)

Even though my desires conflict, I still hold out for the two goals of "working well enough for random people” and “providing a platform for research”. 

I hunger for the first, because we want people to be able to use CeroWrt right away and not be scared off. (Rich’s Rule of Trial Software: Each hurdle that you place in someone’s way reduces the potential audience by half. :-) I am hopeful that we can find default settings that are “good enough” for all link layers so that new people can see an improvement with CeroWrt. I am also mindful that the features will likely wind up in OpenWrt unchanged; it’s worth struggling a bit with the GUI so that we minimize the folklore and misinformation surrounding its use.

The tester in me also is rooting for the second goal. We need to be able to test and tweak the entire queueing system. Making some of it accessible via the GUI will make it easier to experiment, but of course, limits the kinds of changes that could be made. (The lua scripts, though, do give a lot of flexibility.)

On to more concrete ideas:

- From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.

- Would it be possible to keep from mentioning tc_stab in the GUI? 

Thanks!

Rich

PS That was a nice discussion of the (wackiness of) ATM framing.

[-- Attachment #2: Type: text/html, Size: 7448 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 1181 bytes --]

On Tue, 17 Dec 2013, Rich Brown wrote:

> - From what you’ve said, I don’t have much hope for doing it automagically. 
> But maybe we can provide clues to help the customer do to the right thing. 
> Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or 
> ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” 
> and maybe others. CeroWrt could automatically set the proper link layer 
> adaptations for each. We could also include a link to the wiki for a flow 
> chart for setting each of these cases, especially the questions they should 
> ask their ISP.

Let's start with the first question, what is the difference between these as far 
as what the config should be?

forget the GUI or automated settings. If I am configuring a Cerowrt box 
mmanually, what should I set differently for the different types of configs?

What is the impact of getting it wrong? (if it's like VPN overhead where setting 
the rate just slightly too high results is lots of wasted 'airtime' by setting 
it too low results is a amall amount of wasted 'airtime' then a low enough value 
to be reasonalbe everywere is a good default)

David Lang

[-- Attachment #2: Type: TEXT/PLAIN, Size: 164 bytes --]

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi David,

On Dec 18, 2013, at 05:34 , David Lang <david@lang.hm> wrote:

> On Tue, 17 Dec 2013, Rich Brown wrote:
> 
>> - From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
> 
> Let's start with the first question, what is the difference between these as far as what the config should be?

	1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link layer has to be set to ADSL
	2) PTM based carriers (VDSL2): link layer has to be set to ethernet
	3) cable, GPON (fiber): link layer has to be set to ethernet

	1) and 2) typically have additional overhead to account for, 3) may or may not

	Only 3) with no overhead is fine with no link layer adaptation mechanism.

> 
> forget the GUI or automated settings. If I am configuring a Cerowrt box mmanually, what should I set differently for the different types of configs?
	Current GUI settings (might change)
A) ATM based transports:
	1) Which link layer adaptation mechanism: tc_stab
	2) link layer: ADSL
	3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/  (section: Overhead and MTU Calculations)
B) PTM based transports:
	1) Which link layer adaptation mechanism: tc_stab
	2) link layer: ethernet
	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-

C)  cable, GPON (fiber):
	1) Which link layer adaptation mechanism: none, assuming no per packet overhead
otherwise
	1) Which link layer adaptation mechanism: tc_stab
	2) link layer: ethernet
	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-

There should be no need to fiddle with the advanced link layer options, unless you link MTU is >> 1500. Note for link layer ethernet no size table is constructed unless MPU > 0.


> 
> What is the impact of getting it wrong? (if it's like VPN overhead where setting the rate just slightly too high results is lots of wasted 'airtime' by setting it too low results is a amall amount of wasted 'airtime' then a low enough value to be reasonalbe everywere is a good default)

	User on an ATM based link without link layer adaptation: The shaper will underestimate the relevant wire seize of each packet and hence will not shape enough to avoid filling the potentially bloated buffers of the DSL modem. This effect gets worse the more the packet length distribution is skewed towards small packet (the estimate can be off by around 50% worst case, so this is not good.) But note this basically is the "status quo" for most users (as far as I know no router/modem sets these options correctly, but I do not claim to know all such systems). ALSO this in theory is testable, on such a system buffer bloat/latency increase should be more severe if one tries to fill the nominal transmit rates with small than with large packets. Misjudging the overhead either wastes bandwidth or also if too large or increases the likelihood to see buffer bloat by overestimating the effective link capacity.

	Users on a  PTM based link, when running with link layer ADSL, will waste 10% of the bandwidth right there (for taking the 48 in 53 encapsulation into consideration). Plus they will overestimate the effective size of small packets and will waste up to 50% of the remaining bandwidth there. Overhead misjudging has the same effect as on ATM (except overheads on PTM typically should be smaller I guess so this effect might not be too relevant).

	To summarize, using the wrong link layer adaptation will hurt the user, ATM users will suffer buffer bloat, but will use all available bandwidth (well more actually since that creates the bloat), PTM users will suffer severe packet-size-dependent bandwidth decreases. The "status quo" is more or less fine for groups 2) and 3), not so good for 1). I think most people in 1) caring enough reduced the shaped rates by a larger amount than people in groups 2) and 3) and just accepted that depending on the packet size mix latencies got more variable. 

	Getting it wrong is not advisable… Getting it right requires some non-obvious information from one's ISP. While VDSL will become more prominent in the future, ADSL variants will not disappear for a long time, as VDSL only works (well) 
on short loops, so people far away from the DSLAM will stay on ATM (or one day a new ADSL might learn to use PTM, but I will not hold my breath)

Best Regards
	Sebastian

> 
> David Lang_______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

VDSL2 uses PTM. In the UK, the regulator has mandated that VDSL2 must be 
run over fibre, normally to an MSAN within 200-300 metres of the user.

So what is the fibre in your cable and fibre category?

Is it FTTC/FTTH as I describe, or fibre using some other transmission 
protocol?


On 18/12/13 10:33, Sebastian Moeller wrote:
> Hi David,
>
> On Dec 18, 2013, at 05:34 , David Lang <david@lang.hm> wrote:
>
>> On Tue, 17 Dec 2013, Rich Brown wrote:
>>
>>> - From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
>> Let's start with the first question, what is the difference between these as far as what the config should be?
> 	1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link layer has to be set to ADSL
> 	2) PTM based carriers (VDSL2): link layer has to be set to ethernet
> 	3) cable, GPON (fiber): link layer has to be set to ethernet
>
> 	1) and 2) typically have additional overhead to account for, 3) may or may not
>
> 	Only 3) with no overhead is fine with no link layer adaptation mechanism.
>
>> forget the GUI or automated settings. If I am configuring a Cerowrt box mmanually, what should I set differently for the different types of configs?
> 	Current GUI settings (might change)
> A) ATM based transports:
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ADSL
> 	3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/  (section: Overhead and MTU Calculations)
> B) PTM based transports:
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ethernet
> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>
> C)  cable, GPON (fiber):
> 	1) Which link layer adaptation mechanism: none, assuming no per packet overhead
> otherwise
> 	1) Which link layer adaptation mechanism: tc_stab
> 	2) link layer: ethernet
> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>
> There should be no need to fiddle with the advanced link layer options, unless you link MTU is >> 1500. Note for link layer ethernet no size table is constructed unless MPU > 0.
>
>
>> What is the impact of getting it wrong? (if it's like VPN overhead where setting the rate just slightly too high results is lots of wasted 'airtime' by setting it too low results is a amall amount of wasted 'airtime' then a low enough value to be reasonalbe everywere is a good default)
> 	User on an ATM based link without link layer adaptation: The shaper will underestimate the relevant wire seize of each packet and hence will not shape enough to avoid filling the potentially bloated buffers of the DSL modem. This effect gets worse the more the packet length distribution is skewed towards small packet (the estimate can be off by around 50% worst case, so this is not good.) But note this basically is the "status quo" for most users (as far as I know no router/modem sets these options correctly, but I do not claim to know all such systems). ALSO this in theory is testable, on such a system buffer bloat/latency increase should be more severe if one tries to fill the nominal transmit rates with small than with large packets. Misjudging the overhead either wastes bandwidth or also if too large or increases the likelihood to see buffer bloat by overestimating the effective link capacity.
>
> 	Users on a  PTM based link, when running with link layer ADSL, will waste 10% of the bandwidth right there (for taking the 48 in 53 encapsulation into consideration). Plus they will overestimate the effective size of small packets and will waste up to 50% of the remaining bandwidth there. Overhead misjudging has the same effect as on ATM (except overheads on PTM typically should be smaller I guess so this effect might not be too relevant).
>
> 	To summarize, using the wrong link layer adaptation will hurt the user, ATM users will suffer buffer bloat, but will use all available bandwidth (well more actually since that creates the bloat), PTM users will suffer severe packet-size-dependent bandwidth decreases. The "status quo" is more or less fine for groups 2) and 3), not so good for 1). I think most people in 1) caring enough reduced the shaped rates by a larger amount than people in groups 2) and 3) and just accepted that depending on the packet size mix latencies got more variable.
>
> 	Getting it wrong is not advisable… Getting it right requires some non-obvious information from one's ISP. While VDSL will become more prominent in the future, ADSL variants will not disappear for a long time, as VDSL only works (well)
> on short loops, so people far away from the DSLAM will stay on ATM (or one day a new ADSL might learn to use PTM, but I will not hold my breath)
>
> Best Regards
> 	Sebastian
>
>> David Lang_______________________________________________
>> 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

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Fred,


On Dec 18, 2013, at 12:27 , Fred Stratton <fredstratton@imap.cc> wrote:

> VDSL2 uses PTM.

	This is what I understand from the available information as well. Also I think that even VDSL1 typically uses PTM, but my knowledge in these matters is quite limited, (I am neither a telco nor do I work for one)

> In the UK, the regulator has mandated that VDSL2 must be run over fibre, normally to an MSAN within 200-300 metres of the user.
> 
> So what is the fibre in your cable and fibre category?

	Fiber as in 3) of my mail would be fiber to the home FTTH. So typically a fiber modem at the home that "speaks" ethernet to the internal network. Sidenote, to keep things cheap these Modems typically are not set up in a switched fashion, but rather with a hub, each modem sees several users traffic, but will only transmit traffic for its MAC (I think) into each home; giving a clear upgrade patch should residential fiber become too slow :) .
	The important part is the last mile, basically were the bottleneck link sits. Even if a VDSL "DSLAM" would be connected to the ISP backbone via an ATM link (and there is no reason I know why you could not run ATM over fiber), from the users perspective this would not make link layer ADSL the correct choice, assuming the DSLAM backbone connection typically is not the bottleneck. (And even then all users would need to adapt for ATM for it to be useful; but all of this seems rather theoretical as there seems to be a push for telcos to consolidate on ethernet as infrastructure, as I understand it).

> 
> Is it FTTC/FTTH as I describe, or fibre using some other transmission protocol?

	What you scribe is FFTC, and as stated above we are mostly interested in the DSLAM to MODEM link.

I hope to have cleared thngs up…

best
	Sebastian

> 
> 
> On 18/12/13 10:33, Sebastian Moeller wrote:
>> Hi David,
>> 
>> On Dec 18, 2013, at 05:34 , David Lang <david@lang.hm> wrote:
>> 
>>> On Tue, 17 Dec 2013, Rich Brown wrote:
>>> 
>>>> - From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
>>> Let's start with the first question, what is the difference between these as far as what the config should be?
>> 	1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link layer has to be set to ADSL
>> 	2) PTM based carriers (VDSL2): link layer has to be set to ethernet
>> 	3) cable, GPON (fiber): link layer has to be set to ethernet
>> 
>> 	1) and 2) typically have additional overhead to account for, 3) may or may not
>> 
>> 	Only 3) with no overhead is fine with no link layer adaptation mechanism.
>> 
>>> forget the GUI or automated settings. If I am configuring a Cerowrt box mmanually, what should I set differently for the different types of configs?
>> 	Current GUI settings (might change)
>> A) ATM based transports:
>> 	1) Which link layer adaptation mechanism: tc_stab
>> 	2) link layer: ADSL
>> 	3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/  (section: Overhead and MTU Calculations)
>> B) PTM based transports:
>> 	1) Which link layer adaptation mechanism: tc_stab
>> 	2) link layer: ethernet
>> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>> 
>> C)  cable, GPON (fiber):
>> 	1) Which link layer adaptation mechanism: none, assuming no per packet overhead
>> otherwise
>> 	1) Which link layer adaptation mechanism: tc_stab
>> 	2) link layer: ethernet
>> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>> 
>> There should be no need to fiddle with the advanced link layer options, unless you link MTU is >> 1500. Note for link layer ethernet no size table is constructed unless MPU > 0.
>> 
>> 
>>> What is the impact of getting it wrong? (if it's like VPN overhead where setting the rate just slightly too high results is lots of wasted 'airtime' by setting it too low results is a amall amount of wasted 'airtime' then a low enough value to be reasonalbe everywere is a good default)
>> 	User on an ATM based link without link layer adaptation: The shaper will underestimate the relevant wire seize of each packet and hence will not shape enough to avoid filling the potentially bloated buffers of the DSL modem. This effect gets worse the more the packet length distribution is skewed towards small packet (the estimate can be off by around 50% worst case, so this is not good.) But note this basically is the "status quo" for most users (as far as I know no router/modem sets these options correctly, but I do not claim to know all such systems). ALSO this in theory is testable, on such a system buffer bloat/latency increase should be more severe if one tries to fill the nominal transmit rates with small than with large packets. Misjudging the overhead either wastes bandwidth or also if too large or increases the likelihood to see buffer bloat by overestimating the effective link capacity.
>> 
>> 	Users on a  PTM based link, when running with link layer ADSL, will waste 10% of the bandwidth right there (for taking the 48 in 53 encapsulation into consideration). Plus they will overestimate the effective size of small packets and will waste up to 50% of the remaining bandwidth there. Overhead misjudging has the same effect as on ATM (except overheads on PTM typically should be smaller I guess so this effect might not be too relevant).
>> 
>> 	To summarize, using the wrong link layer adaptation will hurt the user, ATM users will suffer buffer bloat, but will use all available bandwidth (well more actually since that creates the bloat), PTM users will suffer severe packet-size-dependent bandwidth decreases. The "status quo" is more or less fine for groups 2) and 3), not so good for 1). I think most people in 1) caring enough reduced the shaped rates by a larger amount than people in groups 2) and 3) and just accepted that depending on the packet size mix latencies got more variable.
>> 
>> 	Getting it wrong is not advisable… Getting it right requires some non-obvious information from one's ISP. While VDSL will become more prominent in the future, ADSL variants will not disappear for a long time, as VDSL only works (well)
>> on short loops, so people far away from the DSLAM will stay on ATM (or one day a new ADSL might learn to use PTM, but I will not hold my breath)
>> 
>> Best Regards
>> 	Sebastian
>> 
>>> David Lang_______________________________________________
>>> 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
> 
> 

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

That does make things clearer. I was conflating FTTC and FTTH, as I was 
making an incorrect assumption about FTTH terminal equipment.

I probably should now run your script at some point to determine which 
overhead value I should use.


On 18/12/13 11:59, Sebastian Moeller wrote:
> Hi Fred,
>
>
> On Dec 18, 2013, at 12:27 , Fred Stratton <fredstratton@imap.cc> wrote:
>
>> VDSL2 uses PTM.
> 	This is what I understand from the available information as well. Also I think that even VDSL1 typically uses PTM, but my knowledge in these matters is quite limited, (I am neither a telco nor do I work for one)
>
>> In the UK, the regulator has mandated that VDSL2 must be run over fibre, normally to an MSAN within 200-300 metres of the user.
>>
>> So what is the fibre in your cable and fibre category?
> 	Fiber as in 3) of my mail would be fiber to the home FTTH. So typically a fiber modem at the home that "speaks" ethernet to the internal network. Sidenote, to keep things cheap these Modems typically are not set up in a switched fashion, but rather with a hub, each modem sees several users traffic, but will only transmit traffic for its MAC (I think) into each home; giving a clear upgrade patch should residential fiber become too slow :) .
> 	The important part is the last mile, basically were the bottleneck link sits. Even if a VDSL "DSLAM" would be connected to the ISP backbone via an ATM link (and there is no reason I know why you could not run ATM over fiber), from the users perspective this would not make link layer ADSL the correct choice, assuming the DSLAM backbone connection typically is not the bottleneck. (And even then all users would need to adapt for ATM for it to be useful; but all of this seems rather theoretical as there seems to be a push for telcos to consolidate on ethernet as infrastructure, as I understand it).
>
>> Is it FTTC/FTTH as I describe, or fibre using some other transmission protocol?
> 	What you scribe is FFTC, and as stated above we are mostly interested in the DSLAM to MODEM link.
>
> I hope to have cleared thngs up…
>
> best
> 	Sebastian
>
>>
>> On 18/12/13 10:33, Sebastian Moeller wrote:
>>> Hi David,
>>>
>>> On Dec 18, 2013, at 05:34 , David Lang <david@lang.hm> wrote:
>>>
>>>> On Tue, 17 Dec 2013, Rich Brown wrote:
>>>>
>>>>> - From what you’ve said, I don’t have much hope for doing it automagically. But maybe we can provide clues to help the customer do to the right thing. Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others. CeroWrt could automatically set the proper link layer adaptations for each. We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
>>>> Let's start with the first question, what is the difference between these as far as what the config should be?
>>> 	1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link layer has to be set to ADSL
>>> 	2) PTM based carriers (VDSL2): link layer has to be set to ethernet
>>> 	3) cable, GPON (fiber): link layer has to be set to ethernet
>>>
>>> 	1) and 2) typically have additional overhead to account for, 3) may or may not
>>>
>>> 	Only 3) with no overhead is fine with no link layer adaptation mechanism.
>>>
>>>> forget the GUI or automated settings. If I am configuring a Cerowrt box mmanually, what should I set differently for the different types of configs?
>>> 	Current GUI settings (might change)
>>> A) ATM based transports:
>>> 	1) Which link layer adaptation mechanism: tc_stab
>>> 	2) link layer: ADSL
>>> 	3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/  (section: Overhead and MTU Calculations)
>>> B) PTM based transports:
>>> 	1) Which link layer adaptation mechanism: tc_stab
>>> 	2) link layer: ethernet
>>> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>>>
>>> C)  cable, GPON (fiber):
>>> 	1) Which link layer adaptation mechanism: none, assuming no per packet overhead
>>> otherwise
>>> 	1) Which link layer adaptation mechanism: tc_stab
>>> 	2) link layer: ethernet
>>> 	3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based-
>>>
>>> There should be no need to fiddle with the advanced link layer options, unless you link MTU is >> 1500. Note for link layer ethernet no size table is constructed unless MPU > 0.
>>>
>>>
>>>> What is the impact of getting it wrong? (if it's like VPN overhead where setting the rate just slightly too high results is lots of wasted 'airtime' by setting it too low results is a amall amount of wasted 'airtime' then a low enough value to be reasonalbe everywere is a good default)
>>> 	User on an ATM based link without link layer adaptation: The shaper will underestimate the relevant wire seize of each packet and hence will not shape enough to avoid filling the potentially bloated buffers of the DSL modem. This effect gets worse the more the packet length distribution is skewed towards small packet (the estimate can be off by around 50% worst case, so this is not good.) But note this basically is the "status quo" for most users (as far as I know no router/modem sets these options correctly, but I do not claim to know all such systems). ALSO this in theory is testable, on such a system buffer bloat/latency increase should be more severe if one tries to fill the nominal transmit rates with small than with large packets. Misjudging the overhead either wastes bandwidth or also if too large or increases the likelihood to see buffer bloat by overestimating the effective link capacity.
>>>
>>> 	Users on a  PTM based link, when running with link layer ADSL, will waste 10% of the bandwidth right there (for taking the 48 in 53 encapsulation into consideration). Plus they will overestimate the effective size of small packets and will waste up to 50% of the remaining bandwidth there. Overhead misjudging has the same effect as on ATM (except overheads on PTM typically should be smaller I guess so this effect might not be too relevant).
>>>
>>> 	To summarize, using the wrong link layer adaptation will hurt the user, ATM users will suffer buffer bloat, but will use all available bandwidth (well more actually since that creates the bloat), PTM users will suffer severe packet-size-dependent bandwidth decreases. The "status quo" is more or less fine for groups 2) and 3), not so good for 1). I think most people in 1) caring enough reduced the shaped rates by a larger amount than people in groups 2) and 3) and just accepted that depending on the packet size mix latencies got more variable.
>>>
>>> 	Getting it wrong is not advisable… Getting it right requires some non-obvious information from one's ISP. While VDSL will become more prominent in the future, ADSL variants will not disappear for a long time, as VDSL only works (well)
>>> on short loops, so people far away from the DSLAM will stay on ATM (or one day a new ADSL might learn to use PTM, but I will not hold my breath)
>>>
>>> Best Regards
>>> 	Sebastian
>>>
>>>> David Lang_______________________________________________
>>>> 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
>>

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Rich Brown]

I like David Lang’s questions:

1) If we had “full knowledge” of the customer’s link, how many different cases would we have to take into account?

2) What happens if we get it wrong?

And I think I understand Sebastian Moeller’s answers:

1) People using ATM-based carriers need the ATM link layer adaptation calculation; others (PTM, Cable, Fiber, etc.) don’t need that calculation.

2) Getting it wrong hurts in each case, but it seems worse where people are using PTM or Ethernet-based links since they lose 10% of their bandwidth due to the 48 in 53 bytes encapsulation. Failure to use the ATM calculation over an ATM-based link makes VoIP etc. less good and fails to make CeroWrt stand out as a great solution, but it’s the status quo for the entire world.

If the choices are as “simple” as this (and please correct me if I’m wrong :-) we really want to find a way to encourage people to use the ATM calculation when it’s warranted. We could hope that they find their way to the AQM tab (before their eyes glaze over), but that seems too big a hurdle.

Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)

Best,

Rich

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Rich,


On Dec 18, 2013, at 14:58 , Rich Brown <richb.hanover@gmail.com> wrote:

> I like David Lang’s questions:
> 
> 1) If we had “full knowledge” of the customer’s link, how many different cases would we have to take into account?
> 
> 2) What happens if we get it wrong?
> 
> And I think I understand Sebastian Moeller’s answers:
> 
> 1) People using ATM-based carriers need the ATM link layer adaptation calculation; others (PTM, Cable, Fiber, etc.) don’t need that calculation.

	Except even with PTM or Fiber there still might be the need to specify an overhead (e.g. 8 bytes for PPPoE) in this case one needs to select the "ethernet" link layer...

> 
> 2) Getting it wrong hurts in each case, but it seems worse where people are using PTM or Ethernet-based links since they lose 10% of their bandwidth due to the 48 in 53 bytes encapsulation. Failure to use the ATM calculation over an ATM-based link makes VoIP etc. less good and fails to make CeroWrt stand out as a great solution, but it’s the status quo for the entire world.

	Or we could say, the default should be ATM so that the ATM latency is under control again, while PTM users just sacrifice some (considerable) amount of bandwidth :)


> 
> If the choices are as “simple” as this (and please correct me if I’m wrong :-) we really want to find a way to encourage people to use the ATM calculation when it’s warranted. We could hope that they find their way to the AQM tab (before their eyes glaze over), but that seems too big a hurdle.

	So I changed the link layer tab a bit, hopefully making clearer which link layer to select...

> 
> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)

	I am happy to include a link to a wiki, but I guess we first need a wiki page :) 

Best
	Sebastian

> 
> Best,
> 
> Rich

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Rich Brown]

Hi Sebastian,

>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
> 
> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :) 

Is this a challenge? Well, I accept! :-)

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.

Please send me comments (or edit the page directly, if you have permissions.) Thanks.

Rich

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Rich,


On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:

> Hi Sebastian,
> 
>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>> 
>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :) 
> 
> Is this a challenge? Well, I accept! :-)
> 
> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.

	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.

> 
> Please send me comments (or edit the page directly, if you have permissions.)

	I do not have edit permissions, so I just comments here.

Basic settings:
	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?

Queueing Discipline:
	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.

Link Layer Adaptation:
	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.

	If the answer to any of these questions is yes, one needs to activate the link layer adaptations. 
	In case of pure overhead select ethernet, in case of ADSL select ATM.
	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).

What’s going on here? Why do I need this?:
	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).

Best Regards
	Sebastian



> Thanks.
> 
> Rich

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

On 19/12/13 11:31, Fred Stratton wrote:
> 3 comments.
>
> Presumably you want these changes for some future use of the interface 
> by a wider audience, rather than current users of ceroWRT.
>
> There is an requirement for this less sophisticated user to turn AQM 
> on for ADSL. There are far more ADSL users than those who use fibre or 
> cable.  In the UK, offered a choice, about only 25 per cent of ADSL 
> users migrate to fibre. The figure for cable is 10 per cent. This is 
> in a fairly open market with competition.
>
> I would argue that the default should be 'on'.
>
> You state the choice in the interface pull down should be 'ethernet or 
> 'atm'. Currently it is 'ethernet' or 'adsl', which semantically makes 
> more sense, even though it uses a mystic, undocumented tc-stab option, 
> namely 'adsl'.
>
> The 'adsl' option appears to work, which is why I advocate it.
>
> Finally, the fourth of these 3 comments...
>
> OpenWRT developers are working on the TP-LINK TD-W8970, a gateway 
> device containing a Lantiq SoC. The device is cheaper in Europe than 
> the US for a change.
>
> Lantiq apparently have open-sourced their code, and the device will be 
> able to connect to the internet via ADSL2 or VDSL2, extending its 
> capabilities.
>
> Your interface will need to be modified again for a gateway device, 
> rather than a router.
>
>
> On 19/12/13 10:49, Sebastian Moeller wrote:
>> Hi Rich,
>>
>>
>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>>>> Perhaps we could extend the Interface configuration page to add a 
>>>>> “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. 
>>>>> Default would be off, but when customers go to the GE00 interface 
>>>>> to enter their PPPoE/PPPoATM/ISP credentials, they’d see this 
>>>>> additional checkbox. Checking it would feed that info to the AQM 
>>>>> tab. (And perhaps there could be a link there either to the AQM 
>>>>> tab, or to the wiki for more information.)
>>>>     I am happy to include a link to a wiki, but I guess we first 
>>>> need a wiki page :)
>>> Is this a challenge? Well, I accept! :-)
>>>
>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 
>>> is a draft. I recycled the images from a previous message and wrote 
>>> the least amount that I could that is likely to be true.
>>     This is great, thanks a lot. I have made a few changes to the GUI 
>> yesterday, which hopefully improve the usability, so if the new GUI 
>> passes muster with the cerowrt crowd, the screenshots will need to 
>> change as you note on top.
>>
>>> Please send me comments (or edit the page directly, if you have 
>>> permissions.)
>>     I do not have edit permissions, so I just comments here.
>>
>> Basic settings:
>>     Why 85% as starting point? And can we give instructions how to 
>> measure "degradation in performance", so that non-technical users 
>> have a chance to actually optimize their own system?
>>
>> Queueing Discipline:
>>     Maybe we can add a link to the mail list page 
>> (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>     Also can we note that it is recommended to turn ECN off for the 
>> egress, as we handle packets before the bottleneck and dropping 
>> packets actually allows us to send other more urgent packets , while 
>> on ingress it is recommended to turn ECN on, as the packets have 
>> cleared the bottleneck already, and hence dropping has no bandwidth 
>> advantage anymore. Both dropping and ECN should have the same effect 
>> on TCP adaptation to the path capacity.
>>
>> Link Layer Adaptation:
>>     I think the first question is: Do I have an ATM carrier between 
>> your modem and your ISP's DSLAM? This typically is true for all ADSL 
>> variants.
>>     The second question is: Do I have overhead on the link outside of 
>> Ethernet framing? This typically is true for users of PPPoE and 
>> PPPoATM and even Bridging I think.
>>
>>     If the answer to any of these questions is yes, one needs to 
>> activate the link layer adaptations.
>>     In case of pure overhead select ethernet, in case of ADSL select 
>> ATM.
>>     Fill in the per packet overhead in byte (see: 
>> http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, 
>> http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ 
>> and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is 
>> zero and no ATM carrier is used, then select "none" for link layer 
>> adaptation. (I changed this page, so the tc_stab htb_private 
>> selection is under advanced options, and there is a selection of 
>> "none", "ethernet", and "none" in the first drop down box, "none" 
>> disables the link layer adaptation. Also the drop down box contains 
>> some information which selection is relevant for which cases).
>>
>> What’s going on here? Why do I need this?:
>>     I think we should mention that only with the proper link layer 
>> selected and the overhead specified cerowrt is able to assess how 
>> large each packet is on the link to the ISP, and only then the 
>> shaping is deterministic. (For ATM users without the adaptations the 
>> shaper is stochastically too optimistic about the link capacity 
>> (which is too say the shaper is too optimistic about the effective 
>> packet sizes)).
>>
>> Best Regards
>>     Sebastian
>>
>>
>>
>>> Thanks.
>>>
>>> Rich
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Fred,


On Dec 19, 2013, at 12:32 , Fred Stratton <fredstratton@imap.cc> wrote:

> 
> On 19/12/13 11:31, Fred Stratton wrote:
>> 3 comments.
>> 
>> Presumably you want these changes for some future use of the interface by a wider audience, rather than current users of ceroWRT.

	Oh, my goal is not so much "world domination" but rather making the link layer adjustments first class citizens in cerowrt's guy; if this should make it into openWRT I would not be unhappy, but it is not one of my personal goals.

>> 
>> There is an requirement for this less sophisticated user to turn AQM on for ADSL. There are far more ADSL users than those who use fibre or cable.  In the UK, offered a choice, about only 25 per cent of ADSL users migrate to fibre. The figure for cable is 10 per cent. This is in a fairly open market with competition.
>> 
>> I would argue that the default should be 'on'.

	Ah, the DSL users really do need to set the right overhead as well for the link layer adaptation to work well, otherwise the padding of the packet due to the quantization is wrong (not a total loss if the number of packets is large enough this could/should average out). So I am not sure whether default on will lead to happiness all around.

>> 
>> You state the choice in the interface pull down should be 'ethernet or 'atm'. Currently it is 'ethernet' or 'adsl', which semantically makes more sense, even though it uses a mystic, undocumented tc-stab option, namely 'adel'.

	Well, I changed it to ATM in the last version, as that is what is relevant for the link layer. So if in the future ADSL3 uses PTM we do not care :) Adel, did I write that? If so I can assure you I intended to write ADSL in lower case, it is just my on-line spell checker that corrects me badly...

>> 
>> The 'adsl' option appears to work, which is why I advocate it.

	for tc and the kernel atm and adsl are the same, just two different names for the same thing. I think we should use ATM instead of ADSL for reasons hinted at above.
 
>> 
>> Finally, the fourth of these 3 comments...
>> 
>> OpenWRT developers are working on the TP-LINK TD-W8970, a gateway device containing a Lantiq SoC. The device is cheaper in Europe than the US for a change.

	Cheaper is good, but the other specs do not seem to exciting, 64MB ram 8Mb rom, only 2.4GHz radio (given the flakiness of both 2.4 and 5GHz I think it nice to have options :) )

>> 
>> Lantiq apparently have open-sourced their code, and the device will be able to connect to the internet via ADSL2 or VDSL2, extending its capabilities.
>> 
>> Your interface will need to be modified again for a gateway device, rather than a router.

	What is the difference between a gateway device and a router?

Best Regards
	Sebastian

>> 
>> 
>> On 19/12/13 10:49, Sebastian Moeller wrote:
>>> Hi Rich,
>>> 
>>> 
>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>> 
>>>> Hi Sebastian,
>>>> 
>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>    I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>> Is this a challenge? Well, I accept! :-)
>>>> 
>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>    This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>> 
>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>    I do not have edit permissions, so I just comments here.
>>> 
>>> Basic settings:
>>>    Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>> 
>>> Queueing Discipline:
>>>    Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>    Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>> 
>>> Link Layer Adaptation:
>>>    I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>    The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>> 
>>>    If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>    In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>    Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>> 
>>> What’s going on here? Why do I need this?:
>>>    I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>> 
>>> Best Regards
>>>    Sebastian
>>> 
>>> 
>>> 
>>>> Thanks.
>>>> 
>>>> Rich
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

On 19/12/13 13:13, Sebastian Moeller wrote:
> Hi Fred,
>
>
> On Dec 19, 2013, at 12:32 , Fred Stratton <fredstratton@imap.cc> wrote:
>
>> On 19/12/13 11:31, Fred Stratton wrote:
>>> 3 comments.
>>>
>>> Presumably you want these changes for some future use of the interface by a wider audience, rather than current users of ceroWRT.
> 	Oh, my goal is not so much "world domination" but rather making the link layer adjustments first class citizens in cerowrt's guy; if this should make it into openWRT I would not be unhappy, but it is not one of my personal goals.
I suspect all your work will end up in openWRT.
>>> There is an requirement for this less sophisticated user to turn AQM on for ADSL. There are far more ADSL users than those who use fibre or cable.  In the UK, offered a choice, about only 25 per cent of ADSL users migrate to fibre. The figure for cable is 10 per cent. This is in a fairly open market with competition.
>>>
>>> I would argue that the default should be 'on'.
> 	Ah, the DSL users really do need to set the right overhead as well for the link layer adaptation to work well, otherwise the padding of the packet due to the quantization is wrong (not a total loss if the number of packets is large enough this could/should average out). So I am not sure whether default on will lead to happiness all around.

OK, I now understand your reasoning.
>
>>> You state the choice in the interface pull down should be 'ethernet or 'atm'. Currently it is 'ethernet' or 'adsl', which semantically makes more sense, even though it uses a mystic, undocumented tc-stab option, namely 'adel'.
> 	Well, I changed it to ATM in the last version, as that is what is relevant for the link layer. So if in the future ADSL3 uses PTM we do not care :) Adel, did I write that? If so I can assure you I intended to write ADSL in lower case, it is just my on-line spell checker that corrects me badly...

OK, if the choice is between 'ethernet' and one renamed option.
>
>>> The 'adsl' option appears to work, which is why I advocate it.
> 	for tc and the kernel atm and adsl are the same, just two different names for the same thing. I think we should use ATM instead of ADSL for reasons hinted at above.
>   
>>> Finally, the fourth of these 3 comments...
>>>
>>> OpenWRT developers are working on the TP-LINK TD-W8970, a gateway device containing a Lantiq SoC. The device is cheaper in Europe than the US for a change.
> 	Cheaper is good, but the other specs do not seem to exciting, 64MB ram 8Mb rom, only 2.4GHz radio (given the flakiness of both 2.4 and 5GHz I think it nice to have options :) )
>
>>> Lantiq apparently have open-sourced their code, and the device will be able to connect to the internet via ADSL2 or VDSL2, extending its capabilities.
>>>
>>> Your interface will need to be modified again for a gateway device, rather than a router.
> 	What is the difference between a gateway device and a router?

A gateway also contains an internal 'modem'. The TD-W8970 has been 
chosen because it uses a Lantiq SoC. The TD-W8980 has all the features 
you desire, but with a Trendchip SoC, and so is of no use for openWRT.
>
> Best Regards
> 	Sebastian
>
>>>
>>> On 19/12/13 10:49, Sebastian Moeller wrote:
>>>> Hi Rich,
>>>>
>>>>
>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>>>
>>>>> Hi Sebastian,
>>>>>
>>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>>     I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>>> Is this a challenge? Well, I accept! :-)
>>>>>
>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>>     This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>>>
>>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>>     I do not have edit permissions, so I just comments here.
>>>>
>>>> Basic settings:
>>>>     Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>>>
>>>> Queueing Discipline:
>>>>     Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>>     Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>>>
>>>> Link Layer Adaptation:
>>>>     I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>>     The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>>>
>>>>     If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>>     In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>>     Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>>>
>>>> What’s going on here? Why do I need this?:
>>>>     I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>>>
>>>> Best Regards
>>>>     Sebastian
>>>>
>>>>
>>>>
>>>>> Thanks.
>>>>>
>>>>> Rich
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

I wanted to say how much I was enjoying catching up on this thread.

I think only one question came up for me during it, which is support
for a bfifo and pfifo qdisc? (if I missed something let me know )
Support for these are darn useful for the research and I have long
meant to fold in the modified code I use for that. Byte limits are
very common for cable and dsl technologies and doing tests with
64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
plots lying about for this, I should put them up somewhere)

Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
It requires that the limit option be dynamic and exposed to the gui,
and in the case of a bfifo is a byte limit rather than a packet limit.
There needs to be sane values for limit clamped somehow, as 1000 bytes
would be bad, and 512000 packets would be bad also.

As for folding the selection of bfifo or pfifo into the gui, it's not
clear that we are doing "researcher mode", vs "mom mode" in a suitably
abstract way. Certainly I can imagine many a researcher wanting the
gui.

While I'm at it, there are some statistics like drops, and backlog,
etc, that a gui-ish interface might help.

polling tc -s qdisc show dev ge00 # and/or class show dev ge00

I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
one box that has now been up 4.4 days with no errors, but I haven't
pushed it. I'll be beating it up through the weekend and taking a look
at the gui work so far.

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Dave,

On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@gmail.com> wrote:

> I wanted to say how much I was enjoying catching up on this thread.
> 
> I think only one question came up for me during it, which is support
> for a bfifo and pfifo qdisc? (if I missed something let me know )
> Support for these are darn useful for the research and I have long
> meant to fold in the modified code I use for that. Byte limits are
> very common for cable and dsl technologies and doing tests with
> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
> plots lying about for this, I should put them up somewhere)
> 
> Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
> It requires that the limit option be dynamic and exposed to the gui,
> and in the case of a bfifo is a byte limit rather than a packet limit.
> There needs to be sane values for limit clamped somehow, as 1000 bytes
> would be bad, and 512000 packets would be bad also.

Mmh, exposing it in the GUI is relatively easy, but probably under a "mere mortals need not go here" class of advanced configuration option (like the fully non checked strings passed to the disc lines :)) 
So we need a qualifier> 1000b or 1000p ? and parse that somewhere. Luci can do some simple checking for us but we can not really interact with the user. Is limit really universal for all discs?

> 
> As for folding the selection of bfifo or pfifo into the gui, it's not
> clear that we are doing "researcher mode", vs "mom mode" in a suitably
> abstract way.

	Well, if we select defaults that work well and mark the options so that it is easy to return to the default state we might be golden…?

> Certainly I can imagine many a researcher wanting the
> gui.

	We can easily give a short description to each "pfifo: prone to long latencies, avoid" ?

> 
> While I'm at it, there are some statistics like drops, and backlog,
> etc, that a gui-ish interface might help.
> 
> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
> 
	I have an idea how to expose the output of these command in the guy (pretty raw) polling or parsing the whole and turn it into something nice is out of my capabilities though.

> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
> one box that has now been up 4.4 days with no errors, but I haven't
> pushed it. I'll be beating it up through the weekend and taking a look
> at the gui work so far.

	Well, running RRUL over the 5GHz got me:
 2931.835937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2933.875000] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2935.910156] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2943.972656] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2948.015625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2978.160156] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2987.226562] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2988.257812] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 2994.320312] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3031.496093] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3035.539062] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3044.609375] ath: phy1: Failed to stop TX DMA, queues=0x00a!
[ 3052.667968] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3083.835937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3101.960937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3108.019531] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3112.062500] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3124.140625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3133.199218] ath: phy1: Failed to stop TX DMA, queues=0x00a!
[ 3138.246093] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3202.542968] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3205.589843] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3209.640625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
[ 3213.691406] ath: phy1: Failed to stop TX DMA, queues=0x00e!


with:
root@nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
    Baseband Hang:  1
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  3
      PLL RX Hang:  0
        MCI Reset:  0
root@nacktmulle:~# 


and:
root@nacktmulle:~# uptime
 21:48:40 up 1 day, 21:29,  load average: 0.00, 0.09, 0.30
root@nacktmulle:~# cat /sys/kernel/debug/mips/unaligned_instructions
9667
root@nacktmulle:~# 


and finally:

[ 8767.437500] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
[ 8767.437500] task: 80331810 ti: 8032a000 task.ti: 8032a000
[ 8767.437500] $ 0   : 00000000 00000000 007c1800 00000001
[ 8767.437500] $ 4   : 0101080a 824d4cc0 80a7a862 00000001
[ 8767.437500] $ 8   : 00000000 f30e0000 00000002 00000000
[ 8767.437500] $12   : dc5d0002 00000001 00000000 00000000
[ 8767.437500] $16   : 822379c0 80a7a862 824d4cc0 00000001
[ 8767.437500] $20   : 80a7a862 80340000 00000006 803abb38
[ 8767.437500] $24   : 00000000 82dd59b0                  
[ 8767.437500] $28   : 8032a000 8032bbb0 803450c8 80251698
[ 8767.437500] Hi    : 0000017f
[ 8767.437500] Lo    : 22e50800
[ 8767.437500] epc   : 80250f04 tcp_validate_incoming+0x88/0x31c
[ 8767.437500]     Not tainted
[ 8767.437500] ra    : 80251698 tcp_rcv_established+0x500/0x650
[ 8767.437500] Status: 1000fc03	KERNEL EXL IE 
[ 8767.437500] Cause : 00800010
[ 8767.437500] BadVA : 80a7a87e
[ 8767.437500] PrId  : 00019374 (MIPS 24Kc)
[ 8767.437500] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
[ 8767.437500] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
[ 8767.437500] Stack : 83826000 00000001 82fdd6b0 c0b3ad20 00000001 00000000 824d4cc0 822379c0
[ 8767.437500] 	  80a7a862 80251698 822d1d80 82dd0eac 00000001 821b4e00 00000000 00000000
[ 8767.437500] 	  8032bc84 824d4cc0 8244c700 822379c0 80a7a84e 80a7a862 80340000 80259798
[ 8767.437500] 	  00000001 8032e57c 80340000 80340000 00000800 80340000 8034472c 80207ae4
[ 8767.437500] 	  8032dddc 83826000 824d4cc0 00000000 824d4cc0 822379c0 80a7a84e 8025bcac
[ 8767.437500] 	  ...
[ 8767.437500] Call Trace:
[ 8767.437500] [<80250f04>] tcp_validate_incoming+0x88/0x31c
[ 8767.437500] [<80251698>] tcp_rcv_established+0x500/0x650
[ 8767.437500] [<80259798>] tcp_v4_do_rcv+0x88/0x290
[ 8767.437500] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
[ 8767.437500] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
[ 8767.437500] [<8020c608>] __netif_receive_skb_core+0x610/0x674
[ 8767.437500] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
[ 8767.437500] [<8020ed78>] net_rx_action+0x88/0x1fc
[ 8767.437500] [<8007e0fc>] __do_softirq+0xc8/0x1b4
[ 8767.437500] [<8007e298>] do_softirq+0x48/0x68
[ 8767.437500] [<8007e4d4>] irq_exit+0x54/0x70
[ 8767.437500] [<8006082c>] ret_from_irq+0x0/0x4
[ 8767.437500] [<80060a60>] __r4k_wait+0x20/0x40
[ 8767.437500] [<8009f178>] cpu_startup_entry+0xa0/0x108
[ 8767.437500] [<80348918>] start_kernel+0x390/0x3b0
[ 8767.437500] 
[ 8767.437500] 
[ 8767.437500] Code: 88c20018  98c2001b  ae020378 <8cc2001c> 1440000e  00000000  08094458  ae00037c  02402021 
[ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
[ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
[ 9444.828125] $ 0   : 00000000 00000000 00866e0d 8d2b68b8
[ 9444.828125] $ 4   : 00000001 0101080a 8109a862 00000040
[ 9444.828125] $ 8   : 00000000 7df00000 00000002 c9b1cb03
[ 9444.828125] $12   : 895f5f4c 00000007 80303fa8 00000000
[ 9444.828125] $16   : 00000040 82401540 822379c0 8109a862
[ 9444.828125] $20   : 00000020 80340000 00000006 803abb38
[ 9444.828125] $24   : 00000000 8023a71c                  
[ 9444.828125] $28   : 8032a000 8032bbd8 803450c8 80259798
[ 9444.828125] Hi    : 00000000
[ 9444.828125] Lo    : 00000000
[ 9444.828125] epc   : 80251264 tcp_rcv_established+0xcc/0x650
[ 9444.828125]     Not tainted
[ 9444.828125] ra    : 80259798 tcp_v4_do_rcv+0x88/0x290
[ 9444.828125] Status: 1000fc03	KERNEL EXL IE 
[ 9444.828125] Cause : 00800010
[ 9444.828125] BadVA : 8109a87e
[ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
[ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
[ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
[ 9444.828125] Stack : 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000 8032bc84 82401540
[ 9444.828125] 	  8244c700 822379c0 8109a84e 8109a862 80340000 80259798 00000001 8032e57c
[ 9444.828125] 	  80340000 80340000 00000800 80340000 8034472c 80207ae4 8032dddc 83826000
[ 9444.828125] 	  82401540 00000000 82401540 822379c0 8109a84e 8025bcac 00000000 8023a390
[ 9444.828125] 	  00000001 80234d2c 83826000 8032d6f8 00000000 00000800 00000000 8032bc84
[ 9444.828125] 	  ...
[ 9444.828125] Call Trace:
[ 9444.828125] [<80251264>] tcp_rcv_established+0xcc/0x650
[ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
[ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
[ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
[ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
[ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
[ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
[ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
[ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
[ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
[ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
[ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
[ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
[ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
[ 9444.828125] 
[ 9444.828125] 
[ 9444.828125] Code: 8a620018  9a62001b  ae420378 <8e64001c> 10800005  00000000  8e4502f8  00852023  080945ef 
[ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
[ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
[ 9444.828125] $ 0   : 00000000 00000000 00866e0d 8d2b68d8
[ 9444.828125] $ 4   : 00000001 0101080a 81972062 00000060
[ 9444.828125] $ 8   : d4d4bb62 80064808 00000002 c9b1cb03
[ 9444.828125] $12   : 895f5f4c 00000007 80303fa8 00000000
[ 9444.828125] $16   : 00000060 824c6b40 822379c0 81972062
[ 9444.828125] $20   : 00000020 80340000 00000006 803abb38
[ 9444.828125] $24   : 00000000 8023a71c                  
[ 9444.828125] $28   : 8032a000 8032bbd8 803450c8 80259798
[ 9444.828125] Hi    : 00000000
[ 9444.828125] Lo    : 00000000
[ 9444.828125] epc   : 80251264 tcp_rcv_established+0xcc/0x650
[ 9444.828125]     Not tainted
[ 9444.828125] ra    : 80259798 tcp_v4_do_rcv+0x88/0x290
[ 9444.828125] Status: 1000fc03	KERNEL EXL IE 
[ 9444.828125] Cause : 00800010
[ 9444.828125] BadVA : 8197207e
[ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
[ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
[ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
[ 9444.828125] Stack : 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000 8032bc84 824c6b40
[ 9444.828125] 	  8244c700 822379c0 8197204e 81972062 80340000 80259798 8032bc84 80234c28
[ 9444.828125] 	  80239fe8 00000001 8032ddd4 80340000 8023a390 824c6b40 8032dddc 83826000
[ 9444.828125] 	  824c6b40 00000000 824c6b40 822379c0 8197204e 8025bcac 00000000 8023a390
[ 9444.828125] 	  00000001 80234d2c 83826000 8032d6f8 00000000 00000800 00000000 8032bc84
[ 9444.828125] 	  ...
[ 9444.828125] Call Trace:
[ 9444.828125] [<80251264>] tcp_rcv_established+0xcc/0x650
[ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
[ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
[ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
[ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
[ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
[ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
[ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
[ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
[ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
[ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
[ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
[ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
[ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
[ 9444.828125] 
[ 9444.828125] 
[ 9444.828125] Code: 8a620018  9a62001b  ae420378 <8e64001c> 10800005  00000000  8e4502f8  00852023  080945ef 
[ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
[ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
[ 9444.828125] $ 0   : 00000000 00000000 00866e0e 00000001
[ 9444.828125] $ 4   : 0101080a 824c6b40 82710862 00000001
[ 9444.828125] $ 8   : 00000000 13700000 00000002 8dcb48f5
[ 9444.828125] $12   : 712a6fab 00000007 00000000 00000000
[ 9444.828125] $16   : 822379c0 82710862 824c6b40 00000001
[ 9444.828125] $20   : 82710862 80340000 00000006 803abb38
[ 9444.828125] $24   : 00000000 8023a71c                  
[ 9444.828125] $28   : 8032a000 8032bbb0 803450c8 80251698
[ 9444.828125] Hi    : 00000000
[ 9444.828125] Lo    : 00000000
[ 9444.828125] epc   : 80250f04 tcp_validate_incoming+0x88/0x31c
[ 9444.828125]     Not tainted
[ 9444.828125] ra    : 80251698 tcp_rcv_established+0x500/0x650
[ 9444.828125] Status: 1000fc03	KERNEL EXL IE 
[ 9444.828125] Cause : 00800010
[ 9444.828125] BadVA : 8271087e
[ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
[ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
[ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
[ 9444.828125] Stack : 83826000 00000000 82fdd6b0 c0b35068 83826000 00000000 824c6b40 822379c0
[ 9444.828125] 	  82710862 80251698 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000
[ 9444.828125] 	  8032bc84 824c6b40 8244c700 822379c0 8271084e 82710862 80340000 80259798
[ 9444.828125] 	  00000001 8032e57c 80340000 80340000 00000800 80340000 8034472c 80207ae4
[ 9444.828125] 	  8032dddc 83826000 824c6b40 00000000 824c6b40 822379c0 8271084e 8025bcac
[ 9444.828125] 	  ...
[ 9444.828125] Call Trace:
[ 9444.828125] [<80250f04>] tcp_validate_incoming+0x88/0x31c
[ 9444.828125] [<80251698>] tcp_rcv_established+0x500/0x650
[ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
[ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
[ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
[ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
[ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
[ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
[ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
[ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
[ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
[ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
[ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
[ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
[ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
[ 9444.828125] 
[ 9444.828125] 
[ 9444.828125] Code: 88c20018  98c2001b  ae020378 <8cc2001c> 1440000e  00000000  08094458  ae00037c  02402021 
[159654.527343] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

Aggh! the unaligned instructions are Baaaaaack? That would explain a lot.

On Fri, Dec 20, 2013 at 12:51 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> I wanted to say how much I was enjoying catching up on this thread.
>>
>> I think only one question came up for me during it, which is support
>> for a bfifo and pfifo qdisc? (if I missed something let me know )
>> Support for these are darn useful for the research and I have long
>> meant to fold in the modified code I use for that. Byte limits are
>> very common for cable and dsl technologies and doing tests with
>> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
>> plots lying about for this, I should put them up somewhere)
>>
>> Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
>> It requires that the limit option be dynamic and exposed to the gui,
>> and in the case of a bfifo is a byte limit rather than a packet limit.
>> There needs to be sane values for limit clamped somehow, as 1000 bytes
>> would be bad, and 512000 packets would be bad also.
>
> Mmh, exposing it in the GUI is relatively easy, but probably under a "mere mortals need not go here" class of advanced configuration option (like the fully non checked strings passed to the disc lines :))
> So we need a qualifier> 1000b or 1000p ? and parse that somewhere. Luci can do some simple checking for us but we can not really interact with the user. Is limit really universal for all discs?
>
>>
>> As for folding the selection of bfifo or pfifo into the gui, it's not
>> clear that we are doing "researcher mode", vs "mom mode" in a suitably
>> abstract way.
>
>         Well, if we select defaults that work well and mark the options so that it is easy to return to the default state we might be golden…?
>
>> Certainly I can imagine many a researcher wanting the
>> gui.
>
>         We can easily give a short description to each "pfifo: prone to long latencies, avoid" ?
>
>>
>> While I'm at it, there are some statistics like drops, and backlog,
>> etc, that a gui-ish interface might help.
>>
>> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
>>
>         I have an idea how to expose the output of these command in the guy (pretty raw) polling or parsing the whole and turn it into something nice is out of my capabilities though.
>
>> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
>> one box that has now been up 4.4 days with no errors, but I haven't
>> pushed it. I'll be beating it up through the weekend and taking a look
>> at the gui work so far.
>
>         Well, running RRUL over the 5GHz got me:
>  2931.835937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2933.875000] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2935.910156] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2943.972656] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2948.015625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2978.160156] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2987.226562] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2988.257812] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 2994.320312] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3031.496093] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3035.539062] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3044.609375] ath: phy1: Failed to stop TX DMA, queues=0x00a!
> [ 3052.667968] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3083.835937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3101.960937] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3108.019531] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3112.062500] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3124.140625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3133.199218] ath: phy1: Failed to stop TX DMA, queues=0x00a!
> [ 3138.246093] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3202.542968] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3205.589843] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3209.640625] ath: phy1: Failed to stop TX DMA, queues=0x00e!
> [ 3213.691406] ath: phy1: Failed to stop TX DMA, queues=0x00e!
>
>
> with:
> root@nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
>     Baseband Hang:  1
> Baseband Watchdog:  0
>    Fatal HW Error:  0
>       TX HW error:  0
>      TX Path Hang:  3
>       PLL RX Hang:  0
>         MCI Reset:  0
> root@nacktmulle:~#
>
>
> and:
> root@nacktmulle:~# uptime
>  21:48:40 up 1 day, 21:29,  load average: 0.00, 0.09, 0.30
> root@nacktmulle:~# cat /sys/kernel/debug/mips/unaligned_instructions
> 9667
> root@nacktmulle:~#
>
>
> and finally:
>
> [ 8767.437500] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
> [ 8767.437500] task: 80331810 ti: 8032a000 task.ti: 8032a000
> [ 8767.437500] $ 0   : 00000000 00000000 007c1800 00000001
> [ 8767.437500] $ 4   : 0101080a 824d4cc0 80a7a862 00000001
> [ 8767.437500] $ 8   : 00000000 f30e0000 00000002 00000000
> [ 8767.437500] $12   : dc5d0002 00000001 00000000 00000000
> [ 8767.437500] $16   : 822379c0 80a7a862 824d4cc0 00000001
> [ 8767.437500] $20   : 80a7a862 80340000 00000006 803abb38
> [ 8767.437500] $24   : 00000000 82dd59b0
> [ 8767.437500] $28   : 8032a000 8032bbb0 803450c8 80251698
> [ 8767.437500] Hi    : 0000017f
> [ 8767.437500] Lo    : 22e50800
> [ 8767.437500] epc   : 80250f04 tcp_validate_incoming+0x88/0x31c
> [ 8767.437500]     Not tainted
> [ 8767.437500] ra    : 80251698 tcp_rcv_established+0x500/0x650
> [ 8767.437500] Status: 1000fc03 KERNEL EXL IE
> [ 8767.437500] Cause : 00800010
> [ 8767.437500] BadVA : 80a7a87e
> [ 8767.437500] PrId  : 00019374 (MIPS 24Kc)
> [ 8767.437500] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
> [ 8767.437500] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
> [ 8767.437500] Stack : 83826000 00000001 82fdd6b0 c0b3ad20 00000001 00000000 824d4cc0 822379c0
> [ 8767.437500]    80a7a862 80251698 822d1d80 82dd0eac 00000001 821b4e00 00000000 00000000
> [ 8767.437500]    8032bc84 824d4cc0 8244c700 822379c0 80a7a84e 80a7a862 80340000 80259798
> [ 8767.437500]    00000001 8032e57c 80340000 80340000 00000800 80340000 8034472c 80207ae4
> [ 8767.437500]    8032dddc 83826000 824d4cc0 00000000 824d4cc0 822379c0 80a7a84e 8025bcac
> [ 8767.437500]    ...
> [ 8767.437500] Call Trace:
> [ 8767.437500] [<80250f04>] tcp_validate_incoming+0x88/0x31c
> [ 8767.437500] [<80251698>] tcp_rcv_established+0x500/0x650
> [ 8767.437500] [<80259798>] tcp_v4_do_rcv+0x88/0x290
> [ 8767.437500] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
> [ 8767.437500] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
> [ 8767.437500] [<8020c608>] __netif_receive_skb_core+0x610/0x674
> [ 8767.437500] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
> [ 8767.437500] [<8020ed78>] net_rx_action+0x88/0x1fc
> [ 8767.437500] [<8007e0fc>] __do_softirq+0xc8/0x1b4
> [ 8767.437500] [<8007e298>] do_softirq+0x48/0x68
> [ 8767.437500] [<8007e4d4>] irq_exit+0x54/0x70
> [ 8767.437500] [<8006082c>] ret_from_irq+0x0/0x4
> [ 8767.437500] [<80060a60>] __r4k_wait+0x20/0x40
> [ 8767.437500] [<8009f178>] cpu_startup_entry+0xa0/0x108
> [ 8767.437500] [<80348918>] start_kernel+0x390/0x3b0
> [ 8767.437500]
> [ 8767.437500]
> [ 8767.437500] Code: 88c20018  98c2001b  ae020378 <8cc2001c> 1440000e  00000000  08094458  ae00037c  02402021
> [ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
> [ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
> [ 9444.828125] $ 0   : 00000000 00000000 00866e0d 8d2b68b8
> [ 9444.828125] $ 4   : 00000001 0101080a 8109a862 00000040
> [ 9444.828125] $ 8   : 00000000 7df00000 00000002 c9b1cb03
> [ 9444.828125] $12   : 895f5f4c 00000007 80303fa8 00000000
> [ 9444.828125] $16   : 00000040 82401540 822379c0 8109a862
> [ 9444.828125] $20   : 00000020 80340000 00000006 803abb38
> [ 9444.828125] $24   : 00000000 8023a71c
> [ 9444.828125] $28   : 8032a000 8032bbd8 803450c8 80259798
> [ 9444.828125] Hi    : 00000000
> [ 9444.828125] Lo    : 00000000
> [ 9444.828125] epc   : 80251264 tcp_rcv_established+0xcc/0x650
> [ 9444.828125]     Not tainted
> [ 9444.828125] ra    : 80259798 tcp_v4_do_rcv+0x88/0x290
> [ 9444.828125] Status: 1000fc03 KERNEL EXL IE
> [ 9444.828125] Cause : 00800010
> [ 9444.828125] BadVA : 8109a87e
> [ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
> [ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
> [ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
> [ 9444.828125] Stack : 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000 8032bc84 82401540
> [ 9444.828125]    8244c700 822379c0 8109a84e 8109a862 80340000 80259798 00000001 8032e57c
> [ 9444.828125]    80340000 80340000 00000800 80340000 8034472c 80207ae4 8032dddc 83826000
> [ 9444.828125]    82401540 00000000 82401540 822379c0 8109a84e 8025bcac 00000000 8023a390
> [ 9444.828125]    00000001 80234d2c 83826000 8032d6f8 00000000 00000800 00000000 8032bc84
> [ 9444.828125]    ...
> [ 9444.828125] Call Trace:
> [ 9444.828125] [<80251264>] tcp_rcv_established+0xcc/0x650
> [ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
> [ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
> [ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
> [ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
> [ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
> [ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
> [ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
> [ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
> [ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
> [ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
> [ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
> [ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
> [ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
> [ 9444.828125]
> [ 9444.828125]
> [ 9444.828125] Code: 8a620018  9a62001b  ae420378 <8e64001c> 10800005  00000000  8e4502f8  00852023  080945ef
> [ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
> [ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
> [ 9444.828125] $ 0   : 00000000 00000000 00866e0d 8d2b68d8
> [ 9444.828125] $ 4   : 00000001 0101080a 81972062 00000060
> [ 9444.828125] $ 8   : d4d4bb62 80064808 00000002 c9b1cb03
> [ 9444.828125] $12   : 895f5f4c 00000007 80303fa8 00000000
> [ 9444.828125] $16   : 00000060 824c6b40 822379c0 81972062
> [ 9444.828125] $20   : 00000020 80340000 00000006 803abb38
> [ 9444.828125] $24   : 00000000 8023a71c
> [ 9444.828125] $28   : 8032a000 8032bbd8 803450c8 80259798
> [ 9444.828125] Hi    : 00000000
> [ 9444.828125] Lo    : 00000000
> [ 9444.828125] epc   : 80251264 tcp_rcv_established+0xcc/0x650
> [ 9444.828125]     Not tainted
> [ 9444.828125] ra    : 80259798 tcp_v4_do_rcv+0x88/0x290
> [ 9444.828125] Status: 1000fc03 KERNEL EXL IE
> [ 9444.828125] Cause : 00800010
> [ 9444.828125] BadVA : 8197207e
> [ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
> [ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
> [ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
> [ 9444.828125] Stack : 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000 8032bc84 824c6b40
> [ 9444.828125]    8244c700 822379c0 8197204e 81972062 80340000 80259798 8032bc84 80234c28
> [ 9444.828125]    80239fe8 00000001 8032ddd4 80340000 8023a390 824c6b40 8032dddc 83826000
> [ 9444.828125]    824c6b40 00000000 824c6b40 822379c0 8197204e 8025bcac 00000000 8023a390
> [ 9444.828125]    00000001 80234d2c 83826000 8032d6f8 00000000 00000800 00000000 8032bc84
> [ 9444.828125]    ...
> [ 9444.828125] Call Trace:
> [ 9444.828125] [<80251264>] tcp_rcv_established+0xcc/0x650
> [ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
> [ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
> [ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
> [ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
> [ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
> [ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
> [ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
> [ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
> [ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
> [ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
> [ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
> [ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
> [ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
> [ 9444.828125]
> [ 9444.828125]
> [ 9444.828125] Code: 8a620018  9a62001b  ae420378 <8e64001c> 10800005  00000000  8e4502f8  00852023  080945ef
> [ 9444.828125] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
> [ 9444.828125] task: 80331810 ti: 8032a000 task.ti: 8032a000
> [ 9444.828125] $ 0   : 00000000 00000000 00866e0e 00000001
> [ 9444.828125] $ 4   : 0101080a 824c6b40 82710862 00000001
> [ 9444.828125] $ 8   : 00000000 13700000 00000002 8dcb48f5
> [ 9444.828125] $12   : 712a6fab 00000007 00000000 00000000
> [ 9444.828125] $16   : 822379c0 82710862 824c6b40 00000001
> [ 9444.828125] $20   : 82710862 80340000 00000006 803abb38
> [ 9444.828125] $24   : 00000000 8023a71c
> [ 9444.828125] $28   : 8032a000 8032bbb0 803450c8 80251698
> [ 9444.828125] Hi    : 00000000
> [ 9444.828125] Lo    : 00000000
> [ 9444.828125] epc   : 80250f04 tcp_validate_incoming+0x88/0x31c
> [ 9444.828125]     Not tainted
> [ 9444.828125] ra    : 80251698 tcp_rcv_established+0x500/0x650
> [ 9444.828125] Status: 1000fc03 KERNEL EXL IE
> [ 9444.828125] Cause : 00800010
> [ 9444.828125] BadVA : 8271087e
> [ 9444.828125] PrId  : 00019374 (MIPS 24Kc)
> [ 9444.828125] Modules linked in: ath9k ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ip6_tunnel tunnel6 tunnel4 ip_tunnel tun tcp_ledbat af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat autofs4 br2684 atm nls_utf8 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 chainiv eseqiv crypto_wq sha1_generic krng rng md5 hmac des_generic deflate zlib_inflate zlib_deflate cbc authenc aead arc4 crypto_blkcipher usb_storage input_polldev leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common crc32c crypto_hash
> [ 9444.828125] Process swapper (pid: 0, threadinfo=8032a000, task=80331810, tls=00000000)
> [ 9444.828125] Stack : 83826000 00000000 82fdd6b0 c0b35068 83826000 00000000 824c6b40 822379c0
> [ 9444.828125]    82710862 80251698 8210a0a4 c0b33000 00000001 821b4e00 00000000 00000000
> [ 9444.828125]    8032bc84 824c6b40 8244c700 822379c0 8271084e 82710862 80340000 80259798
> [ 9444.828125]    00000001 8032e57c 80340000 80340000 00000800 80340000 8034472c 80207ae4
> [ 9444.828125]    8032dddc 83826000 824c6b40 00000000 824c6b40 822379c0 8271084e 8025bcac
> [ 9444.828125]    ...
> [ 9444.828125] Call Trace:
> [ 9444.828125] [<80250f04>] tcp_validate_incoming+0x88/0x31c
> [ 9444.828125] [<80251698>] tcp_rcv_established+0x500/0x650
> [ 9444.828125] [<80259798>] tcp_v4_do_rcv+0x88/0x290
> [ 9444.828125] [<8025bcac>] tcp_v4_rcv+0x430/0x82c
> [ 9444.828125] [<8023a4e0>] ip_local_deliver_finish+0x150/0x28c
> [ 9444.828125] [<8020c608>] __netif_receive_skb_core+0x610/0x674
> [ 9444.828125] [<801f22cc>] ag71xx_poll+0x3b8/0x5c4
> [ 9444.828125] [<8020ed78>] net_rx_action+0x88/0x1fc
> [ 9444.828125] [<8007e0fc>] __do_softirq+0xc8/0x1b4
> [ 9444.828125] [<8007e298>] do_softirq+0x48/0x68
> [ 9444.828125] [<8007e4d4>] irq_exit+0x54/0x70
> [ 9444.828125] [<8006082c>] ret_from_irq+0x0/0x4
> [ 9444.828125] [<80060a60>] __r4k_wait+0x20/0x40
> [ 9444.828125] [<8009f178>] cpu_startup_entry+0xa0/0x108
> [ 9444.828125] [<80348918>] start_kernel+0x390/0x3b0
> [ 9444.828125]
> [ 9444.828125]
> [ 9444.828125] Code: 88c20018  98c2001b  ae020378 <8cc2001c> 1440000e  00000000  08094458  ae00037c  02402021
> [159654.527343] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Dave,


On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@gmail.com> wrote:

> I wanted to say how much I was enjoying catching up on this thread.
> 
> I think only one question came up for me during it, which is support
> for a bfifo and pfifo qdisc? (if I missed something let me know )
> Support for these are darn useful for the research and I have long
> meant to fold in the modified code I use for that. Byte limits are
> very common for cable and dsl technologies and doing tests with
> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
> plots lying about for this, I should put them up somewhere)
> 
> Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
> It requires that the limit option be dynamic and exposed to the gui,
> and in the case of a bfifo is a byte limit rather than a packet limit.
> There needs to be sane values for limit clamped somehow, as 1000 bytes
> would be bad, and 512000 packets would be bad also.
> 

	I just noticed we probably should go for ingress_Limit and egress_Limit as there are different in simple_qos.sh, I assume for a good reason…


best
	sebastian


> As for folding the selection of bfifo or pfifo into the gui, it's not
> clear that we are doing "researcher mode", vs "mom mode" in a suitably
> abstract way. Certainly I can imagine many a researcher wanting the
> gui.
> 
> While I'm at it, there are some statistics like drops, and backlog,
> etc, that a gui-ish interface might help.
> 
> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
> 
> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
> one box that has now been up 4.4 days with no errors, but I haven't
> pushed it. I'll be beating it up through the weekend and taking a look
> at the gui work so far.

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
>
> On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> I wanted to say how much I was enjoying catching up on this thread.
>>
>> I think only one question came up for me during it, which is support
>> for a bfifo and pfifo qdisc? (if I missed something let me know )
>> Support for these are darn useful for the research and I have long
>> meant to fold in the modified code I use for that. Byte limits are
>> very common for cable and dsl technologies and doing tests with
>> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
>> plots lying about for this, I should put them up somewhere)
>>
>> Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
>> It requires that the limit option be dynamic and exposed to the gui,
>> and in the case of a bfifo is a byte limit rather than a packet limit.
>> There needs to be sane values for limit clamped somehow, as 1000 bytes
>> would be bad, and 512000 packets would be bad also.
>>
>
>         I just noticed we probably should go for ingress_Limit and egress_Limit as there are different in simple_qos.sh, I assume for a good reason…


I am not huge on CamelCase or HungarianNotation, or iThinkThis, btw.
The way I tend to think about things is that shell environment
variables tend to be ALLCAPS, and that C and openwrt uci variables
tend to be lowercase. I'm not big on under_scores as they are somewhat
hard to see, and I'm not really sure what luci's PreferredSyntax (?)
is. There are now several different styles running through the
aqm-scripts....

But that said, yes, breaking apart the two limits for egress and
ingress makes sense particularly for the byte limits, where you might
be be emulating a dslam (64k bytes) on one side, and a dumb modem
(256k bytes) on the other.

Elsewhere, prior to now, the limits were there merely to keep memory
usage under control. There is no need for 10k packets worth of
buffering. There is not much need for more than 600 packets ever at
the speeds we are running at today, and usually are in the dozens, so
I'd defaulted to 600 packets on egress and 1000 on ingress as being
big enough limits to nearly never hit on pie and fq_codel.

I really do hate having more knobs that can be messed up.

>
> best
>         sebastian
>
>
>> As for folding the selection of bfifo or pfifo into the gui, it's not
>> clear that we are doing "researcher mode", vs "mom mode" in a suitably
>> abstract way. Certainly I can imagine many a researcher wanting the
>> gui.
>>
>> While I'm at it, there are some statistics like drops, and backlog,
>> etc, that a gui-ish interface might help.
>>
>> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
>>
>> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
>> one box that has now been up 4.4 days with no errors, but I haven't
>> pushed it. I'll be beating it up through the weekend and taking a look
>> at the gui work so far.
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Dave Taht <dave.taht@gmail.com> wrote:
>On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller <moeller0@gmx.de>
>wrote:
>> Hi Dave,
>>
>>
>> On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@gmail.com> wrote:
>>
>>> I wanted to say how much I was enjoying catching up on this thread.
>>>
>>> I think only one question came up for me during it, which is support
>>> for a bfifo and pfifo qdisc? (if I missed something let me know )
>>> Support for these are darn useful for the research and I have long
>>> meant to fold in the modified code I use for that. Byte limits are
>>> very common for cable and dsl technologies and doing tests with
>>> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
>>> plots lying about for this, I should put them up somewhere)
>>>
>>> Sooo... I just checked in the limit stuff (untested) into
>aqm-scripts.
>>> It requires that the limit option be dynamic and exposed to the gui,
>>> and in the case of a bfifo is a byte limit rather than a packet
>limit.
>>> There needs to be sane values for limit clamped somehow, as 1000
>bytes
>>> would be bad, and 512000 packets would be bad also.
>>>
>>
>>         I just noticed we probably should go for ingress_Limit and
>egress_Limit as there are different in simple_qos.sh, I assume for a
>good reason…
>
>
>I am not huge on CamelCase or HungarianNotation, or iThinkThis, btw.
>The way I tend to think about things is that shell environment
>variables tend to be ALLCAPS, and that C and openwrt uci variables
>tend to be lowercase. I'm not big on under_scores as they are somewhat
>hard to see, and I'm not really sure what luci's PreferredSyntax (?)
>is. There are now several different styles running through the
>aqm-scripts....

       Sorry, my bad. I do not really care that much, except I want expressive variable names which tend to be longish. And longish names do need some sort of separation of the parts INGRESSECN is harder to parse for than INGRESS_ECN and like wise for ingressecn and ingress_ecn, and camelcase serves the same purpose just uglier. But from now on I will follow your wishes.

Best
       Sebastian

>
>But that said, yes, breaking apart the two limits for egress and
>ingress makes sense particularly for the byte limits, where you might
>be be emulating a dslam (64k bytes) on one side, and a dumb modem
>(256k bytes) on the other.
>
>Elsewhere, prior to now, the limits were there merely to keep memory
>usage under control. There is no need for 10k packets worth of
>buffering. There is not much need for more than 600 packets ever at
>the speeds we are running at today, and usually are in the dozens, so
>I'd defaulted to 600 packets on egress and 1000 on ingress as being
>big enough limits to nearly never hit on pie and fq_codel.
>
>I really do hate having more knobs that can be messed up.
>
>>
>> best
>>         sebastian
>>
>>
>>> As for folding the selection of bfifo or pfifo into the gui, it's
>not
>>> clear that we are doing "researcher mode", vs "mom mode" in a
>suitably
>>> abstract way. Certainly I can imagine many a researcher wanting the
>>> gui.
>>>
>>> While I'm at it, there are some statistics like drops, and backlog,
>>> etc, that a gui-ish interface might help.
>>>
>>> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
>>>
>>> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I
>have
>>> one box that has now been up 4.4 days with no errors, but I haven't
>>> pushed it. I'll be beating it up through the weekend and taking a
>look
>>> at the gui work so far.
>>

Hi Dave,
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[Cerowrt-devel] CeroWrt 3.10 AQM page

[Rich Brown]

Hi Sebastian and Fred,

[I’m changing the subject line of this thread…]

Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight. 

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310

Rich


On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Rich,
> 
> 
> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
> 
>> Hi Sebastian,
>> 
>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>> 
>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :) 
>> 
>> Is this a challenge? Well, I accept! :-)
>> 
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
> 
> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
> 
>> 
>> Please send me comments (or edit the page directly, if you have permissions.)
> 
> 	I do not have edit permissions, so I just comments here.
> 
> Basic settings:
> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
> 
> Queueing Discipline:
> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
> 
> Link Layer Adaptation:
> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
> 
> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations. 
> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
> 
> What’s going on here? Why do I need this?:
> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
> 
> Best Regards
> 	Sebastian
> 
> 
> 
>> Thanks.
>> 
>> Rich
> 

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Fred Stratton]

2 comments:

You talk about link speed. This has 2 meanings:

the rate at which the link syncs;

the download speed as measured by speedtest.net, or similar site. The 
text should be more specific.

The phrase 'contact your ISP' is in the text.  This should be removed.  
Such contact is a traumatic exercise to which no users of ceroWRT should 
be subjected.


On 19/12/13 13:42, Rich Brown wrote:
> Hi Sebastian and Fred,
>
> [I’m changing the subject line of this thread…]
>
> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>
> Rich
>
>
> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Rich,
>>
>>
>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>> Is this a challenge? Well, I accept! :-)
>>>
>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>
>>> Please send me comments (or edit the page directly, if you have permissions.)
>> 	I do not have edit permissions, so I just comments here.
>>
>> Basic settings:
>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>
>> Queueing Discipline:
>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>
>> Link Layer Adaptation:
>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>
>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>
>> What’s going on here? Why do I need this?:
>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>
>> Best Regards
>> 	Sebastian
>>
>>
>>
>>> Thanks.
>>>
>>> Rich
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Sebastian Moeller]

Hi All,


On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton@ydl.net> wrote:

> 2 comments:
> 
> You talk about link speed. This has 2 meanings:
> 
> the rate at which the link syncs;
> 
> the download speed as measured by speedtest.net, or similar site. The text should be more specific.

	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">

> 
> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.

	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest… 

Best Regards
	Sebastian

> 
> 
> On 19/12/13 13:42, Rich Brown wrote:
>> Hi Sebastian and Fred,
>> 
>> [I’m changing the subject line of this thread…]
>> 
>> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>> 
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>> 
>> Rich
>> 
>> 
>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>>> Hi Rich,
>>> 
>>> 
>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>> 
>>>> Hi Sebastian,
>>>> 
>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>> Is this a challenge? Well, I accept! :-)
>>>> 
>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>> 
>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>> 	I do not have edit permissions, so I just comments here.
>>> 
>>> Basic settings:
>>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>> 
>>> Queueing Discipline:
>>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>> 
>>> Link Layer Adaptation:
>>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>> 
>>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>> 
>>> What’s going on here? Why do I need this?:
>>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>> 
>>> Best Regards
>>> 	Sebastian
>>> 
>>> 
>>> 
>>>> Thanks.
>>>> 
>>>> Rich
>> _______________________________________________
>> 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

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Fred Stratton]

On 19/12/13 15:07, Sebastian Moeller wrote:
> Hi All,
>
>
> On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton@ydl.net> wrote:
>
>> 2 comments:
>>
>> You talk about link speed. This has 2 meanings:
>>
>> the rate at which the link syncs;
>>
>> the download speed as measured by speedtest.net, or similar site. The text should be more specific.
> 	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
> 	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
> 	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">

I do not think the assertion that all DSLAMs are oversubscribed is 
correct. The point I was making was different to the one you are addressing.
>
>> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.
> 	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest…
The ISPs I use have contract support, which changes. They work according 
to a fault-finding script. Even if you are asking a question and do not 
have a fault, they go through the script. I have been through 3 levels 
of tech support, 'gurus', and ISP network support. None can answer 
simple questions.
Germany may be different, but I am paying circa 5 euros a month for 
unlimited internet access by ADSL2+.

I could use a boutique ISP, and get native ipv6 with a /48, and 
intelligent customer support. Downloads are limited to 40GiB per month 
for circa 50 euros.

So here, talking to customer support is not viable.
>
> Best Regards
> 	Sebastian
>
>>
>> On 19/12/13 13:42, Rich Brown wrote:
>>> Hi Sebastian and Fred,
>>>
>>> [I’m changing the subject line of this thread…]
>>>
>>> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>>>
>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>>>
>>> Rich
>>>
>>>
>>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>
>>>> Hi Rich,
>>>>
>>>>
>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>>>
>>>>> Hi Sebastian,
>>>>>
>>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>>> Is this a challenge? Well, I accept! :-)
>>>>>
>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>>>
>>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>> 	I do not have edit permissions, so I just comments here.
>>>>
>>>> Basic settings:
>>>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>>>
>>>> Queueing Discipline:
>>>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>>>
>>>> Link Layer Adaptation:
>>>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>>>
>>>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>>>
>>>> What’s going on here? Why do I need this?:
>>>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>>>
>>>> Best Regards
>>>> 	Sebastian
>>>>
>>>>
>>>>
>>>>> Thanks.
>>>>>
>>>>> Rich
>>> _______________________________________________
>>> 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

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Sebastian Moeller]

Hi Fred,


On Dec 19, 2013, at 16:27 , Fred Stratton <fredstratton@ydl.net> wrote:

> 
> On 19/12/13 15:07, Sebastian Moeller wrote:
>> Hi All,
>> 
>> 
>> On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton@ydl.net> wrote:
>> 
>>> 2 comments:
>>> 
>>> You talk about link speed. This has 2 meanings:
>>> 
>>> the rate at which the link syncs;
>>> 
>>> the download speed as measured by speedtest.net, or similar site. The text should be more specific.
>> 	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
>> 	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
>> 	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">
> 
> I do not think the assertion that all DSLAMs are oversubscribed is correct.

	I would love to hear from people deeper in the know, but as far as I know, the old telephone system was oversubscribed (the central office had less total line equivalents uplink, than subscriber lines connected). I am pretty sure that in Germany DSLAM are always having more total bandwidth on the user side than o the internet side; I do not want to claim that this typically leads to noticeable congestion, as let's face it, most users have very lean bandwidth usage... 

> The point I was making was different to the one you are addressing.

	I thought your point was that iy is not clear which speed to measure; my core point is that it is the speed of the link to the ISP (the DDSLAM not necessarily the BRAS).

>> 
>>> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.
>> 	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest…
> The ISPs I use have contract support, which changes. They work according to a fault-finding script. Even if you are asking a question and do not have a fault, they go through the script. I have been through 3 levels of tech support, 'gurus', and ISP network support. None can answer simple questions.
> Germany may be different, but I am paying circa 5 euros a month for unlimited internet access by ADSL2+.

	This price sounds great (is that all or do you have to pay for a mandatory phone line as well). The situation in Germany is not much better.

> 
> I could use a boutique ISP, and get native ipv6 with a /48, and intelligent customer support. Downloads are limited to 40GiB per month for circa 50 euros.
> 
> So here, talking to customer support is not viable.

	Then the non technical user pretty much is out of luck in getting this information. In that case we might think about defaulting overhead to 40 (the 44 maximum should be really really rare) so that almost all users should be okay… So we are back at needing a reliable robust automatic link layer detection….

best regards
	sebastian



>> 
>> Best Regards
>> 	Sebastian
>> 
>>> 
>>> On 19/12/13 13:42, Rich Brown wrote:
>>>> Hi Sebastian and Fred,
>>>> 
>>>> [I’m changing the subject line of this thread…]
>>>> 
>>>> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>>>> 
>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>>>> 
>>>> Rich
>>>> 
>>>> 
>>>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>> 
>>>>> Hi Rich,
>>>>> 
>>>>> 
>>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>>>> 
>>>>>> Hi Sebastian,
>>>>>> 
>>>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>>>> Is this a challenge? Well, I accept! :-)
>>>>>> 
>>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>>>> 
>>>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>>> 	I do not have edit permissions, so I just comments here.
>>>>> 
>>>>> Basic settings:
>>>>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>>>> 
>>>>> Queueing Discipline:
>>>>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>>>> 
>>>>> Link Layer Adaptation:
>>>>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>>>> 
>>>>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>>>> 
>>>>> What’s going on here? Why do I need this?:
>>>>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>>>> 
>>>>> Best Regards
>>>>> 	Sebastian
>>>>> 
>>>>> 
>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> Rich
>>>> _______________________________________________
>>>> 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
> 

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Fred Stratton]

On 20/12/13 10:12, Sebastian Moeller wrote:
> Hi Fred,
>
>
> On Dec 19, 2013, at 16:27 , Fred Stratton <fredstratton@ydl.net> wrote:
>
>> On 19/12/13 15:07, Sebastian Moeller wrote:
>>> Hi All,
>>>
>>>
>>> On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton@ydl.net> wrote:
>>>
>>>> 2 comments:
>>>>
>>>> You talk about link speed. This has 2 meanings:
>>>>
>>>> the rate at which the link syncs;
>>>>
>>>> the download speed as measured by speedtest.net, or similar site. The text should be more specific.
>>> 	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
>>> 	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
>>> 	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">
>> I do not think the assertion that all DSLAMs are oversubscribed is correct.
> 	I would love to hear from people deeper in the know, but as far as I know, the old telephone system was oversubscribed (the central office had less total line equivalents uplink, than subscriber lines connected). I am pretty sure that in Germany DSLAM are always having more total bandwidth on the user side than o the internet side; I do not want to claim that this typically leads to noticeable congestion, as let's face it, most users have very lean bandwidth usage...
>
>> The point I was making was different to the one you are addressing.
> 	I thought your point was that iy is not clear which speed to measure; my core point is that it is the speed of the link to the ISP (the DDSLAM not necessarily the BRAS).
The end user cannot assess the speed pf the link you mention. There is 
also not necessarily one link only between the telephone exchange 
equipment and the ISP.

Here, BT, the Deutsche Telekom equivalent, does not have a monopoly. It 
has 37 per cent of the retail market. Its wholesale arm, OpenReach, 
operates the infrastructure independently. ISPs only use part of this 
infrastructure.

TalkTalk use BT phone lines from here to the exchange 1.4km away. The 
DSLAM is TalkTalk equipment. The backhaul - fibre along the West Coast 
Main Line- is owned by TalkTalk.

Sky use BT phone lines from here to the exchange 1.4km away. The DSLAM 
is Skyg equipment.The backhaul is owned by BT/OpenReach.

I am talking about the maximum sync rate for the line versus the actual 
achieved rate, which varies more. Bith are available to the end user. 
Both can be used for calculation.
>
>>>> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.
>>> 	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest…
>> The ISPs I use have contract support, which changes. They work according to a fault-finding script. Even if you are asking a question and do not have a fault, they go through the script. I have been through 3 levels of tech support, 'gurus', and ISP network support. None can answer simple questions.
>> Germany may be different, but I am paying circa 5 euros a month for unlimited internet access by ADSL2+.
> 	This price sounds great (is that all or do you have to pay for a mandatory phone line as well). The situation in Germany is not much better.

The phone line, excluding cash discount, costs about 12 euros per month 
extra.
>
>> I could use a boutique ISP, and get native ipv6 with a /48, and intelligent customer support. Downloads are limited to 40GiB per month for circa 50 euros.
>>
>> So here, talking to customer support is not viable.
> 	Then the non technical user pretty much is out of luck in getting this information. In that case we might think about defaulting overhead to 40 (the 44 maximum should be really really rare) so that almost all users should be okay… So we are back at needing a reliable robust automatic link layer detection….
>
> best regards
> 	sebastian
>
>
>
>>> Best Regards
>>> 	Sebastian
>>>
>>>> On 19/12/13 13:42, Rich Brown wrote:
>>>>> Hi Sebastian and Fred,
>>>>>
>>>>> [I’m changing the subject line of this thread…]
>>>>>
>>>>> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>>>>>
>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>>>>>
>>>>> Rich
>>>>>
>>>>>
>>>>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>>>
>>>>>> Hi Rich,
>>>>>>
>>>>>>
>>>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Sebastian,
>>>>>>>
>>>>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>>>>> Is this a challenge? Well, I accept! :-)
>>>>>>>
>>>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>>>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>>>>>
>>>>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>>>> 	I do not have edit permissions, so I just comments here.
>>>>>>
>>>>>> Basic settings:
>>>>>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>>>>>
>>>>>> Queueing Discipline:
>>>>>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>>>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>>>>>
>>>>>> Link Layer Adaptation:
>>>>>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>>>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>>>>>
>>>>>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>>>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>>>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>>>>>
>>>>>> What’s going on here? Why do I need this?:
>>>>>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>>>>>
>>>>>> Best Regards
>>>>>> 	Sebastian
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Rich
>>>>> _______________________________________________
>>>>> 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

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Sebastian Moeller]

Hi Fred,


On Dec 20, 2013, at 11:33 , Fred Stratton <fredstratton@imap.cc> wrote:

> 
> On 20/12/13 10:12, Sebastian Moeller wrote:
>> Hi Fred,
>> 
>> 
>> On Dec 19, 2013, at 16:27 , Fred Stratton <fredstratton@ydl.net> wrote:
>> 
>>> On 19/12/13 15:07, Sebastian Moeller wrote:
>>>> Hi All,
>>>> 
>>>> 
>>>> On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton@ydl.net> wrote:
>>>> 
>>>>> 2 comments:
>>>>> 
>>>>> You talk about link speed. This has 2 meanings:
>>>>> 
>>>>> the rate at which the link syncs;
>>>>> 
>>>>> the download speed as measured by speedtest.net, or similar site. The text should be more specific.
>>>> 	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
>>>> 	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
>>>> 	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">
>>> I do not think the assertion that all DSLAMs are oversubscribed is correct.
>> 	I would love to hear from people deeper in the know, but as far as I know, the old telephone system was oversubscribed (the central office had less total line equivalents uplink, than subscriber lines connected). I am pretty sure that in Germany DSLAM are always having more total bandwidth on the user side than o the internet side; I do not want to claim that this typically leads to noticeable congestion, as let's face it, most users have very lean bandwidth usage...
>> 
>>> The point I was making was different to the one you are addressing.
>> 	I thought your point was that iy is not clear which speed to measure; my core point is that it is the speed of the link to the ISP (the DDSLAM not necessarily the BRAS).
> The end user cannot assess the speed pf the link you mention.

Well typically this, what I call link speed is reported either on the invoice/contract or somewhere on the modems status page.

> There is also not necessarily one link only between the telephone exchange equipment and the ISP.

	As far as I understand the situation the only relevant link for AQM is the slowest dedicated link between us and the backbone. On a DSL line that typically is the copper pair between the DSLAM and the "socket" at the users home. The lines after that are typically shared (and hence larger than thus users dedicated payed-for access rates).  For the shared components of the path we have to hope that the ISP manages these well.

> 
> Here, BT, the Deutsche Telekom equivalent, does not have a monopoly. It has 37 per cent of the retail market. Its wholesale arm, OpenReach, operates the infrastructure independently. ISPs only use part of this infrastructure.
> 
> TalkTalk use BT phone lines from here to the exchange 1.4km away. The DSLAM is TalkTalk equipment. The backhaul - fibre along the West Coast Main Line- is owned by TalkTalk.
> 
> Sky use BT phone lines from here to the exchange 1.4km away. The DSLAM is Skyg equipment.The backhaul is owned by BT/OpenReach.
> 
> I am talking about the maximum sync rate for the line versus the actual achieved rate, which varies more. Bith are available to the end user. Both can be used for calculation.

	Ah, we need the actual current sync rate (not the line capacity). The point is we need to know how fast can we actually push bits over to the DSLAM. This is the speed we need to stay below to avoid filling the ample buffers in the DSL modem on the uplink, and to avoid filling the DSLM's buffer on the downlink. I know that earless rate adaptation SRA will make this somewhat more difficult, it is rarely used.
	Heck what we need is a standardized way for routers to acquire the current up and download speeds from dsl/cable-modems...


>> 
>>>>> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.
>>>> 	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest…
>>> The ISPs I use have contract support, which changes. They work according to a fault-finding script. Even if you are asking a question and do not have a fault, they go through the script. I have been through 3 levels of tech support, 'gurus', and ISP network support. None can answer simple questions.
>>> Germany may be different, but I am paying circa 5 euros a month for unlimited internet access by ADSL2+.
>> 	This price sounds great (is that all or do you have to pay for a mandatory phone line as well). The situation in Germany is not much better.
> 
> The phone line, excluding cash discount, costs about 12 euros per month extra.

	Still a great price.

best
	sebastian

>> 
>>> I could use a boutique ISP, and get native ipv6 with a /48, and intelligent customer support. Downloads are limited to 40GiB per month for circa 50 euros.
>>> 
>>> So here, talking to customer support is not viable.
>> 	Then the non technical user pretty much is out of luck in getting this information. In that case we might think about defaulting overhead to 40 (the 44 maximum should be really really rare) so that almost all users should be okay… So we are back at needing a reliable robust automatic link layer detection….
>> 
>> best regards
>> 	sebastian
>> 
>> 
>> 
>>>> Best Regards
>>>> 	Sebastian
>>>> 
>>>>> On 19/12/13 13:42, Rich Brown wrote:
>>>>>> Hi Sebastian and Fred,
>>>>>> 
>>>>>> [I’m changing the subject line of this thread…]
>>>>>> 
>>>>>> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>>>>>> 
>>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>>>>>> 
>>>>>> Rich
>>>>>> 
>>>>>> 
>>>>>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>>>> 
>>>>>>> Hi Rich,
>>>>>>> 
>>>>>>> 
>>>>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Hi Sebastian,
>>>>>>>> 
>>>>>>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>>>>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>>>>>> Is this a challenge? Well, I accept! :-)
>>>>>>>> 
>>>>>>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>>>>>> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>>>>>> 
>>>>>>>> Please send me comments (or edit the page directly, if you have permissions.)
>>>>>>> 	I do not have edit permissions, so I just comments here.
>>>>>>> 
>>>>>>> Basic settings:
>>>>>>> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>>>>>> 
>>>>>>> Queueing Discipline:
>>>>>>> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>>>>>> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>>>>>> 
>>>>>>> Link Layer Adaptation:
>>>>>>> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>>>>>> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>>>>>> 
>>>>>>> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>>>>>> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
>>>>>>> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>>>>>> 
>>>>>>> What’s going on here? Why do I need this?:
>>>>>>> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>>>>>> 
>>>>>>> Best Regards
>>>>>>> 	Sebastian
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> Rich
>>>>>> _______________________________________________
>>>>>> 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
> 

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Dave Taht]

What's in a name? AQM has been pretty thoroughly defined to equal
active queue *length* management and not packet scheduling.
Overloading "AQM" what cerowrt does is apt to cause even more
confusion in the field than it already does. We discussed using LBO as
a word but that appears hopelessly overloaded with leveraged buy out.

I go back to one I liked a while back:

Smart Queue Management. (SQM)

This got dissed on the aqm list too, but so far a viable alternative
TLA has not appeared. It's sufficiently different to hang a different
definition off of ("Smart queue management is an intelligent
combination of better packet scheduling (flow queuing) techniques
along with with active queue length management (aqm)")


On Thu, Dec 19, 2013 at 5:42 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> Hi Sebastian and Fred,
>
> [I’m changing the subject line of this thread…]
>
> Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight.
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>
> Rich
>
>
> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Rich,
>>
>>
>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>>>
>>>>     I am happy to include a link to a wiki, but I guess we first need a wiki page :)
>>>
>>> Is this a challenge? Well, I accept! :-)
>>>
>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
>>
>>       This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
>>
>>>
>>> Please send me comments (or edit the page directly, if you have permissions.)
>>
>>       I do not have edit permissions, so I just comments here.
>>
>> Basic settings:
>>       Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
>>
>> Queueing Discipline:
>>       Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
>>       Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
>>
>> Link Layer Adaptation:
>>       I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
>>       The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
>>
>>       If the answer to any of these questions is yes, one needs to activate the link layer adaptations.
>>       In case of pure overhead select ethernet, in case of ADSL select ATM.
>>       Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
>>
>> What’s going on here? Why do I need this?:
>>       I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
>>
>> Best Regards
>>       Sebastian
>>
>>
>>
>>> Thanks.
>>>
>>> Rich
>>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Folks,

I have always hungered for a two-part entry for the up and download link speeds. It’s a little bit of a crock to make every customer break out their calculator to compute 95% (or 92% or whatever discount they wish to impose) and type in that computed number.

I think I would prefer to let customers enter the link speed and the discount factor separately, and let the computer figure it out. Something like this photoshopped image:



Or even separate fudge factors for the Download and Upload stats - it would be cool if they were side-by-side, e.g.

Download Speed (kbit/s)    6500     95
Upload Speed (kbit/s)         700       95

@Sebastian: please don’t get heart failure :-) I have no idea whether the luci GUI toolbox gives you this kind of flexibility...

Best,

Rich

[-- Attachment #2.1: Type: text/html, Size: 1348 bytes --]

[-- Attachment #2.2: PastedGraphic-2.tiff --]
[-- Type: image/tiff, Size: 136488 bytes --]

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Sebastian Moeller]

Hi Rich,


On Dec 20, 2013, at 22:25 , Rich Brown <richb.hanover@gmail.com> wrote:

> Folks,
> 
> I have always hungered for a two-part entry for the up and download link speeds. It’s a little bit of a crock to make every customer break out their calculator to compute 95% (or 92% or whatever discount they wish to impose) and type in that computed number.
> 
> I think I would prefer to let customers enter the link speed and the discount factor separately, and let the computer figure it out. Something like this photoshopped image:
> 
> <PastedGraphic-2.tiff>
> 

	This looks quite doable, if we go that route we definitely need independent toggles for up and down (at least as advanced options). What is harder is to actually report back the shaped rates in the GUI, at least with my level of expertise with the GUI and lua that is.

> Or even separate fudge factors for the Download and Upload stats - it would be cool if they were side-by-side, e.g.
> 
> Download Speed (kbit/s)    6500     95
> Upload Speed (kbit/s)         700       95
> 
	That looks nice, no idea yet how to implement that though.


> @Sebastian: please don’t get heart failure :-) I have no idea whether the luci GUI toolbox gives you this kind of flexibility…

	Nor do I. Alas I am off for a two week family holiday away from home, so I will most likely not do any changes/prototyping before next year…

Best Regards
	sebastian

> 
> Best,
> 
> Rich

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Rich Brown]

Folks,

I have updated the CeroWrt 3.10 AQM page. Thanks for all the comments, I’ll incorporate more comments as people send them in. Some thoughts on the page so far:

- I agree that we should keep the descriptions generic (that is, not tailored specifically to CeroWrt) so we can push into OpenWrt without changes. 

- It’s also a good idea to look for good marketing name (SQM, IQM, etc) so that we can tout the goodness of the fq_codel, &c. I’ll submit another proposal on the “Anything but ‘AQM’” thread.

- I removed references to calling the ISP - sometimes it could work, but I see now how it could also be problematic.

- I prefer telling people to decide on their link layer adaptation using the term “ADSL” instead of “ATM” (even though it’s technically more true) since nobody knows what ATM is, and they (most likely) do know whether they have DSL, Cable, Fiber, or something else…

- I wasn’t clear where a decision about overhead of 40 or 44 comes from, or where it should be described.

- Are there any better (but still easy to use) speed test tool besides speedtest.net?

- It’s a good idea to make it easy for people to get back to defaults. Could there be a “Restore Defaults” button on the Basic Settings tab? 

Draft #2 of the Setting up AQM page is available at: http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310

Thanks in advance for all your comments. 

Rich

PS And if you’re running short of things to work on, the new “Quick Test for Bufferbloat” page *really* needs help. 

Re: [Cerowrt-devel] CeroWrt 3.10 AQM page

[Sebastian Moeller]

Rich Brown <richb.hanover@gmail.com> wrote:
>Folks,
>
>I have updated the CeroWrt 3.10 AQM page. Thanks for all the comments,
>I’ll incorporate more comments as people send them in. Some thoughts on
>the page so far:
>
>- I agree that we should keep the descriptions generic (that is, not
>tailored specifically to CeroWrt) so we can push into OpenWrt without
>changes. 
>
>- It’s also a good idea to look for good marketing name (SQM, IQM, etc)
>so that we can tout the goodness of the fq_codel, &c. I’ll submit
>another proposal on the “Anything but ‘AQM’” thread.

Could any of us come up with a decent backronym?


>
>- I removed references to calling the ISP - sometimes it could work,
>but I see now how it could also be problematic.

      Too bad since the ISP will have this information available, the alternatives are Google and luck or long measurements...

>
>- I prefer telling people to decide on their link layer adaptation
>using the term “ADSL” instead of “ATM” (even though it’s technically
>more true) since nobody knows what ATM is, and they (most likely) do
>know whether they have DSL, Cable, Fiber, or something else

      I think ATM is the way to go, otherwise those unlucky souls on VDSL links with ATM carriers will be quite confused. And in case ADSL should learn to use PTM instead the GUI and wiki will still be okay... Assuming the users are willing to learn ATM might work...


>
>- I wasn’t clear where a decision about overhead of 40 or 44 comes
>from, or where it should be described

     44 seems to be worst case overhead for DSL over atm , so defaulting to 44 would work for everybody, wasting some bytes per packet for most. 40 seems to be the largest size that is actually common, wasting less for everyone... Both of these are with PPPoE. I had a look at tomato's and gargoyle, one of the tomato's let's the user select the encapsulation from a long list, the other one automatically selects link layer ADSL when pppoe is in use. I argue that both methods are suboptimal, the former assumes quite a bit of information from the user, the latter has too many false positives (in Germany vdsl2 typically uses pppoe but PTM).


>
>- Are there any better (but still easy to use) speed test tool besides
>speedtest.net?

      I think these tools pretty much all are not too helpful for our purpose as they measure average bandwidth over the whole path, while we need slowest non-shared link, aka the bottleneck we can actually reliably affect with sqm

>
>- It’s a good idea to make it easy for people to get back to defaults.
>Could there be a “Restore Defaults” button on the Basic Settings tab? 


      Not sure, the queueing setup script selection is quite nonstandard...
>
>Draft #2 of the Setting up AQM page is available at:
>http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
>
>Thanks in advance for all your comments.

      Thanks for creating this, the next version of the GUI will contain a link. It would be excellent if we could have a new name by then...

>
>Rich
>
>PS And if you’re running short of things to work on, the new “Quick
>Test for Bufferbloat” page *really* needs help. 

Hi Rich,
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Rich,


On Dec 18, 2013, at 04:06 , Rich Brown <richb.hanover@gmail.com> wrote:

> Hi Sebastian,
> 
>>> And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL;
>> 
>> 	No ADLS is one out of a family of xDSLs (digital subscriber lines). As far as I know SDSL does not use ATM, VDSL1 might use ATM and all ADSL variants use ATM.
>> 
>>> and where ethernet fits into the scheme of things.
>> 
>> 	Ethernet is also a link layer, one that does typically not show quantization as ATM does, selecting the ethernet link layer allows to still specify an overhead, and that is somewhat useful for VDSL (since VDSL often still uses PPPoE).
> 
> ... and ...
> 
>>> - (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) 
>> 
>> 	Well for PPPoATM I agree, but PPPoE is also used with VDSL which uses PTM in stead of ATM and has no quantization issues, but still profits from setting the overhead correctly so needs the link layer adaptation as well. Now, as far as I know PPPoATM is quite rare so I have no idea of how to deal with the common case automagically.
> 
> So basically, if I understand what you’re saying, it’s a big mess. :-)

	At least as far as I understand it; there might be simple and elegant solution to this, I just do not see it...

> 
> Even though my desires conflict, I still hold out for the two goals of "working well enough for random people” and “providing a platform for research”. 
> 
> I hunger for the first, because we want people to be able to use CeroWrt right away and not be scared off. (Rich’s Rule of Trial Software: Each hurdle that you place in someone’s way reduces the potential audience by half. :-) I am hopeful that we can find default settings that are “good enough” for all link layers so that new people can see an improvement with CeroWrt. I am also mindful that the features will likely wind up in OpenWrt unchanged; it’s worth struggling a bit with the GUI so that we minimize the folklore and misinformation surrounding its use.
> 
> The tester in me also is rooting for the second goal. We need to be able to test and tweak the entire queueing system. Making some of it accessible via the GUI will make it easier to experiment, but of course, limits the kinds of changes that could be made. (The lua scripts, though, do give a lot of flexibility.)

	Well the biggest problem I see is that people on an ATM link really really need the link layer adaptation so that the shaper actually can work properly at all (otherwise they need to shape down a lot from the nominal link speed to reduce the probability of filling the modems buffers by underestimating the wire size/transfer time of packets). All other people would rather not do this as the 48 in 53 encapsulation reduces the rate to ~90% of the link speed and this is without thinking about the last cell padding. In short there is not one link layer setting that will be satisfactory for all users. (One could argue that to give the ATM users a good out of box experience the default should be link layer ADSL, and everyone else (vdsl2, cable, fiber) just sacrifices some bandwidth; compared to everyone being happy out of the box except the ADSL users…). I guess, this is something that the user will need to configure… (Also the overhead can not be really predicted so either we take the maximum possible, 44 bytes, or risk bad out-of-box experience for some users…)
	Automatic detection of the link layer as  implemented it takes a link time (several hours) during which the internet connection must not be loaded, so seems infeasible to run from the GUI for technically naive users; think "a modal box saying: please wait 3 hours until the link layer detection has finished". (The trick is to repeatedly measure the RTT at 3 different packet sizes, N, N + 24, N+ 48, so that two of these are guaranteed to have the same atm cell count, while the third is either once atm cell shorter or longer. Then statistically test for significance of differences and declare it ATM based if really two measurement sizes are significantly different from the third. The catch is that at the higher end of DSL say 16Mbit/s down (2097152 byte/s),  2.8Mbit/s up (367001.6)) the amount of RTT added by a single atm cell is quite small (around 0.15ms) compared to the RTT variance you typically get with say ping so it takes a lot of measurements to get the significance high...


> 
> On to more concrete ideas:
> 
> - From what you’ve said, I don’t have much hope for doing it automagically.

	I concur ...

> But maybe we can provide clues to help the customer do to the right thing.

	We can and should try. Since the whole issue is a mess any recommendations will not be terrible concise though.

> Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” 

	Technically the ATM part is the relevant part, the ADSL name is only in there as too few people know about the actually carrier (and they should not need to, ATM on ADSL links should just be phased out and forgotten, but I digress)

> with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others
> . CeroWrt could automatically set the proper link layer adaptations for each. \

	Would be nice, but people typically do not know the link layer their internet connection uses as ISPs do not mention this as far as I know. But as a first approximation we could say: ADSL users need to set the link layer, cable, fiber, vdsl2 users do not. But once people have too look up the relevant overhead it gets complicated no matter what...

> We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
> 
> - Would it be possible to keep from mentioning tc_stab in the GUI? 

	Well, I am going to hide the selection between tc_stab and htb_private behind and "advanced details" checkbox, sounds okay?

> 
> Thanks!
> 
> Rich
> 
> PS That was a nice discussion of the (wackiness of) ATM framing.

Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Fred Stratton]

Most work here also. I have babel turned off at present.

SM worked until 0300 CET crafting the AQM lua interface. The result is 
clearer IMHO. The balance is about right. Thank you.

DT recrafted the wifi script after visiting the cinema. I wonder if 
3.10.24-5 is the precursor to Mordor builds as successors to Vancouver.


On 16/12/13 13:45, Rich Brown wrote:
> Dave, List,
>
>> + hopefully nasty interface initialization bug fixed
>> http://www.bufferbloat.net/issues/437
> In a one-out-of-one test, this build causes all six wireless interfaces to start up: CEROwrt (and guest) on 2.4 and 5 GHz, and both babel SSID’s.
>
> In addition, the ‘wifi’ command does not give any diagnostic output as I had mentioned in my earlier message.
>
> Keepin’ my fingers crossed.
>
> Rich
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel