[OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
In looking over the enormous stack of boards and drivers that openwrt supports, I see that many of the ethernet drivers don't yet support Linux 3.3's Byte Queue Limits, which are discussed here: http://lwn.net/Articles/454390/ It would be good if more did. They improve network performance in the general case enormously, particularly when a link is not connected at it's peak wire speed. *Adding* support for BQL to an ethernet driver is trivial, here's an example of how. http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch * testing BQL* is also trivial - but will require the device to do. I've been beat up by memory barrier issues and stuff like that, so it pays to do the patch and then run serious tests through it, rather than try it blind. So, getting more BQL enabled ethernet drivers working would be good. There is BQL support in many of the mainstream ethernet cards already, see those for more examples of how to do it. ... Anyway, as folk are hopefully aware by now, Kathie Nichols and Van Jacobson have released a new no knobs AQM algorithm which can be used by default on all interfaces - not just the uplink - in order to manage bandwidth and latency far better than has ever been done before. If you haven't heard about it yet, please see http://queue.acm.org/detail.cfm?id=2209336 for the paper. Figure 7 shows the enormous differences in latency and buffering behavior between drop tail (the current linux default), RED, and Codel. There's also been good coverage in lwn, jim gettys blog, arstechnica, etc. I'd ignore slashdot. Codel is a brand new algorithm, something truly new under the sun, which doesn't happen every day. Kathie and Van been working on it for over a decade and the bufferbloat/cerowrt team for over a year. We took the wraps off the algorithm a few days ago. We've made the code freely available under a dual BSD/GPL license. AQM is not just for routers anymore, either, but it helps a lot there! Versions of Codel for linux 3.3 and 3.4 (and ns2 and ns3 simulations) are here: http://www.bufferbloat.net/projects/codel/wiki Codel will work best on a BQL-enabled ethernet driver. It will also work on devices with small numbers of ring buffers. I look forward to hearing of early successes (and failures!) on various bits of hardware. Certainly while codel + bql works well, htb and hfsc in combination with various other technologies is not well tested yet. Codel is a RED replacement, and will work best when paired up with QFQ, or the upcoming sfq-enabled version. However by itself it's pretty darn good, and can be used on all interfaces of a router, not just the uplink. Work on characterizing wireless behavior is on-going. (some help on that would be nice) There is still a great deal of work ahead for the cerowrt project, it's my hope that by sharing this stuff as soon as I felt the patches were baked enough, that all those frustrated by network delays and bufferbloat on supposedly fast hardware, would jump on it, on their own hardware. Our intent from day one was to get Codel into OpenWrt (and indeed, all OSes) as fast as possible. Unfortunately I kind of forgot about getting BQL on everything, everywhere, too! -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
On 10/05/12 17:57, Dave Taht wrote: In looking over the enormous stack of boards and drivers that openwrt supports, I see that many of the ethernet drivers don't yet support Linux 3.3's Byte Queue Limits, which are discussed here: http://lwn.net/Articles/454390/ It would be good if more did. They improve network performance in the general case enormously, particularly when a link is not connected at it's peak wire speed. *Adding* support for BQL to an ethernet driver is trivial, here's an example of how. http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch * testing BQL* is also trivial - but will require the device to do. I've been beat up by memory barrier issues and stuff like that, so it pays to do the patch and then run serious tests through it, rather than try it blind. Hi, do you run specific tests or just hammer the unit ? john ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
On Thu, May 10, 2012 at 9:13 AM, John Crispin j...@phrozen.org wrote: On 10/05/12 17:57, Dave Taht wrote: In looking over the enormous stack of boards and drivers that openwrt supports, I see that many of the ethernet drivers don't yet support Linux 3.3's Byte Queue Limits, which are discussed here: http://lwn.net/Articles/454390/ It would be good if more did. They improve network performance in the general case enormously, particularly when a link is not connected at it's peak wire speed. *Adding* support for BQL to an ethernet driver is trivial, here's an example of how. http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch * testing BQL* is also trivial - but will require the device to do. I've been beat up by memory barrier issues and stuff like that, so it pays to do the patch and then run serious tests through it, rather than try it blind. Hi, do you run specific tests or just hammer the unit ? Hammering via any means is good - netperf, iperf, apache benchmarks, etc. We have been using (and improving) netperf to exercise things like classification and alternate tcp algorithms. You can get that from netperf.org's svn, or There is a version of that already packaged up in the openwrt compatible ceropackages repository here: https://github.com/dtaht/ceropackages-3.3 the new (to be 2.6) version of netperf is not backward compatible with version 2.5, so all sides of the connection need to be running it. useful tests are TCP_STREAM, TCP_MAERTS, and TCP_RR, run multiple times simultaneously, for long periods. (memory barriers are hard to hit). Codel shows up well in a simultaneous TCP_STREAM and TCP_RR test vs pfifo_fast, too. Iperf is a simpler substitute. john ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Information required on AR7240 ethernet switch
Hello Everyone, Can anyone provide information on queries asked in my last post on AR7240 ethernet switch? Query posted again below: AR7240 has integrtaed 803.2 ethernet switch with five 10/100 Mbps Fast ethernet MAC/PHY. We want to do loopback test on the ethernet peripheral of AP91. I had few questions here: 1. AR7240 ethernet reigisters shows two bits for loopback a. In MAC configuration 1 register, bit 8: Enabling this as we understand enables MAC loopback. b. Port Control register, bit 12: Description of register says Setting this bit to 1 enables the MAC loopback function on MII interface As we understand this is MII loopback and enabling just this bit (with MAC configuration register bit 8 reset) we should have MII loopback. Is the understanding correct here for MII loopback, does ar7240 switch support MII loopback? 2. Does the switch support PHY loopback and how do we enable that? 3. Which ethernet switch from atheros is used in AR7240? I basically need information on what all ethernet loopback modes AR7240 support and how to enable that. Any response would be appreciated. Thanks, Parul On Wed, May 9, 2012 at 1:35 PM, Parul Aggarwal parul.aggar...@sibridgetech.com wrote: Hi Everyone, AR7240 has integrtaed 803.2 ethernet switch with five 10/100 Mbps Fast ethernet MAC/PHY. We want to do loopback test on the ethernet peripheral of AP91. I had few questions here: 1. AR7240 ethernet reigisters shows two bits for loopback a. In MAC configuration 1 register, bit 8: Enabling this as we understand enables MAC loopback. b. Port Control register, bit 12: Description of register says Setting this bit to 1 enables the MAC loopback function on MII interface As we understand this is MII loopback and enabling just this bit (with MAC configuration register bit 8 reset) we should have MII loopback. Is the understanding correct here for MII loopback, does ar7240 switch support MII loopback? 2. Does the switch support PHY loopback and how do we enable that? 3. Which ethernet switch from atheros is used in AR7240? I basically need information on what all ethernet loopback modes AR7240 support and how to enable that. Any help would be appreciated. Regards, Parul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
