Posted Dec 7, 2011 19:38 UTC (Wed) by mtaht (✭ supporter ✭, #11087)
Parent article: Some Cerowrt updates
The recent adoption of Byte Queue Limits (BQL) into the kernel, successes regarding using things like HTB, QFQ, and RED to bound latency better, and the current discussions involving using Time in Queue, make me feel as though we're about to turn back the tide of bufferbloat, linux-wide. Far more thought, engineering, and testing will be required, of course...
That's what's driving me to think about shooting the other technological puppies, and/or adopting different ones.
I'm glad we now have - as we needed so badly back in june - a reliable, fully debugged, well understood wireless test routing platform in the wndr3700v2 and wndr3800.
However almost all the good stuff that happened this year has been pushed up into openwrt and/or into the mainline kernel. I'd like to go lean and mean with cerowrt, and try to track the BQL development process closely next quarter.
At this point, the only things I'm certain will be in cerowrt-rc8 (or whatever we end up calling it, as having 'release candidates' at this point seems to be resembling 'Duke Nukem Forever') are BQL, and some advanced AQMs.
The uptime on the router where we first got DNSSEC to work is currently:
21:57:14 up 213 days, 13:39, load average: 0.00, 0.01, 0.04
It was a wonderful weekend, when we did that. People said it couldn't be done. Proof of concept, on just that one concept, achieved!
Not a lot of progress on DNSSEC since, as it turns out that getting this ONE new BIT in DNS handled correctly is going to be a PITA. The 'right' way to do it is to create a standard for getaddrinfo that makes sense, and I'm not the guy to do it.
I'm hoping that there is someone out there that thinks DNSSEC is important enough to more fully deploy. I think it's very important, but at the moment, I'd rather rest up over the holiday, and then go back to beating the bloat.
Details on what the 'right thing' to do for DNSSEC are at: