History

« Previous - Version 11/27 (diff) - Next » - Current version
Dave Täht, 01/30/2012 03:44 pm

BQL series release notes

BQL smoketest 27

http://huchra.bufferbloat.net/~cero1/bql-smoketests/bql-27/

BQL-27 is the third public release of a BQL enabled kernel build for cerowrt.

The primary purpose is to test the BQL, improved SFQ, RED, and SFQRED subsystems.
It should be possible now to thoroughly debloat ethernet behavior, as well as
upstream dsl/ethernet behavior. Wireless remains a major problem, and is likely
to remain one until a thorough redesign takes place of the aggregation and AP
layers.

A great deal of additional stuff is included by default, of varying quality. Due to the size of this build, no jffs2 version will be available, only the squashfs version works for wndr3700v2 and wndr3800.

I note that the wndr3700v3 has hit the stores and IS NOT compatible with the v2. Get a 3800 if you want to be future proofed.

Features:

  • Kernel 3.2.2 + 3.3 backport of the new BQL and new AQM technologies
  • + Everything that's ever been in cerowrt before! (ipv6,mesh networking,bind9,etc)
  • +
  • BQL (Byte Queue Limits)
  • RED fixed, adaptive RED implemented, SFQ vastly expanded in capability, and SFQRED added
  • TX rings increased (thx to BQL)
  • debloat script uses sfq instead of txqueuelen
  • Samba 3.6.1 #314
  • Strongswan 4.5.3 See #318
  • Working ahcp See #252 #322
  • Working isc-bind9 See #316
  • Working isc-ntp See #316 #280
  • iperf installed by default (because netperf is so new)
  • netperf upgraded to svn head
    This breaks backward compatibility with older versions of netperf. To use netperf, you will have to install a new version from svn.
    The principal reason for this upgrade was to gain remote TOS/diffserv setting, as well as alternate tcp algorithm support.
  • and much much more.

bql-27 meets the original base feature set intended for rc7.

Some core features may be added, others dropped, as being discussed on the mailing list.

Stability

Several hundred GB have been sent through the router with no crashes. Performance is good. SFQ does wonders under load for things like voip, short connections, and dns.

Known Bugs

  • QFQ does not work (hangs under load)
  • The old openwrt AQM shaper is lame. See #331
  • SFQ is underconfigured on all interfaces. See #305
  • Dibbler segvios and does not configure ipv6 interfaces. See #274
  • PIM based multicast does not work (uftpd fails)
  • SFQ on an AP is not the best thing for packet aggregation
  • SFQ may now be 'over-optimized' for low latency. See #332

You'll note that none of these issues are essential for normal operation.
Normal operation is pretty fine, actually.

Dave's Goals

1) After evaluating the performance of the current openwrt-based AQM system, a
substitute will be implemented. #306 Regrettably the primary prototype of that
was QFQ based. #312 The SFQRED implementation will be used instead, which should
work well, except with bittorrent. Unless I figure out how to do the same
thing with DRR, or get QFQ working.

2) A gui for creating the AQMs and measuring bandwidth will be added
#306

3) Hopefully the wins related bugs with XP vs Vista will be resolved
by somebody. #314 I still lack hardware to test that. I do not intend to
actually ship samba pre-installed at this point, but can be persuaded
otherwise if something can be made to 'just work'.

4) Working ds-lite support (dibbler? wide? what?) #274

Dave's wish list

Please give this one a shot. It's the first build to show significant differences in performance since
august. Actually, most bottlenecks have moved to my laptop(s) and servers! I suggest running BQL enabled
kernels on your desktops/laptops with the 'debloat' script in order to see best results.

the debloat repository is being maintained separately from cerowrt:

https://github.com/dtaht/deBloat

see src/debloat.

A lot of glue is required as yet to make the various pieces function smoothly,
but I do hope you notice a difference in overall performance in normal use. With a new external AQM we'll do
better, but I'd like people to be exercising that code, suggesting features, etc, before I commit
to starting up a more formal release cycle, and product definition.

I am still toying with the idea of moving forward directly into Linux 3.3, rather than continuing
to backport to 3.2.

That said, I won't be hurt if you delay until after I get the newest AQM installed and working by default.

My hope would be mid-feburary for that.