Well there is a lot of stuff that has been fed into 2.6.39 and later that came <br>from the debloating work. In particular ECN and DSCP should 'just work'<br>now under all circumstances (or so I hope) on both ipv6 and ipv4.<br>
<br>So at the moment, debloat-testing is looking rather bare, but it's been surving <br>a purpose.<br><br>My personal problem is that I've been unable to convince any custom kernel<br>to compile and run on ubuntu 10.10 on my laptop, which really hinders my own efforts. (jg has been able to build debs that work, but for some reason I can't.<br>
It's embarrasing)<br><br>There have been so many ecn and dscp fixes pushed that the old debloat-testing<br>was getting useless for that stuff, so I thank you for getting it done today.<br><br>Moving forward...<br><br>
I've been thinking about building kvm based openwrt versions of debloat-testing... Someone could run multiple ones at the same time and watch the traffic go by, much like how strongswan does it's testing, here:<br>
<br><a href="http://www.strongswan.org/uml-testing.html">http://www.strongswan.org/uml-testing.html</a><br><br>and we could start getting more reproducable results from everyone. <br><br>People could fiddle with the gui. play with shapers. Stuff like that. <br>
<br>It also would be kind of helpful to be able to boot a kernel and small os<br>from a memory stick or ramdisk at this point.<br><br>(and I rather dislike mucking with my laptop anyway)<br><br>High on my want-to-do-but-mostly-wish-someone-else-would-do list are:<br>
<br>0) Add ecn support to HTB, and the other common shapers. <br> 1) debloating a string of common ethernet drivers, adding ethtool where needed<br>2) working on vastly improving packet classification techniques with DSCP.<br>
3) Making 802.11e 'just work' (see 2)<br>4) fiddling with netem to simulate delays<br>5) fidding with gred (why only 16 queues? why not 64??? Easy patch...)<br> Does gred even work? nobody's touched the code since, like mid-05<br>
6) writing a replacement for pfifo_fast<br>7) coming up with a sane way to measure the effect of massive multicast packets' <br> and feed that back into qdisc estimators<br>8) Moving the cerowrt/wndr work forward to 3.0 from the heavily-now-backported<br>
stuff in 2.6.37.6...<br><br>Re: 0)<br><br> Logic:<br>
<br>
mark_or_drop_packet(skb) - returns 0 if dropped, 1 if marked, 2 if already marked, -1 on error<br> (or whatever)<br>
<br> Just that much would make me happy from a testing perspective. HTB drops an extraordinary number of packets under load. A slight optimization would be to try harder to shoot non-ecn packets, so trying a few more (4? 2?) buckets upon detection of a (currently) rare already ecn marked packet would be nice.<br>
<br>
a problem is actually pushing a common infrastructure statistics infrastructure for marking/dropping into the rest of the stack which I don't care about...<br><br> While there is architecture in the kernel for seeing what packets are being dropped<br>
and why, nobody is paying much attention to it. <br><br> CONFIG_NET_DROP_MONITOR and CONFIG_SCHED_NETEM are <br> looking more useful by the day.<br><br>Re: 2) - I finally got to where I was happy with the comprehensive Diffserv classifier. <br>
<br>I like it. Being able to clearly see all the Mice packets and other packet types against typical traffic is a real boon, and the code now works on openwrt and more normal Linux boxes. <br><br>It works well mostly - With the plethora of iptables rules, it slows a router capable of 150Mb/sec down to under 40. Fixing it is relatively easy by adding some smarter<br>
support for table lookups and priority reclassification in iptables...<br><br>(git repo: <a href="https://github.com/dtaht/Diffserv">https://github.com/dtaht/Diffserv</a> - I note that to work right, this requires recently fixed bugs in netfilter (and/or debloat-testing or 3.0-rc2 or cerowrt))<br>
<br>Anyway... I really don't care about the performance issue right now, I wanted, now that traffic was comprehensively classified, to start feeding it into the appropriate shapers, and of course, ran smack in gred's 16 queue limitation, just to start with. And then pfifo_fast started bugging me, in that I wanted more fairness to all flows in the final qdisc...<br>
<br>and then I decided that if I merely got a usable build done of cerowrt-dbg for<br>the wndr that someone else could use, I'd take the afternoon off.<br><br>It's up. It's working...<br><br><a href="http://huchra.bufferbloat.net/~cerowrt/cerowrt-wndr3700-dbg/">http://huchra.bufferbloat.net/~cerowrt/cerowrt-wndr3700-dbg/</a><br>
<br>I'm outta here. Happy downloading. The nanostation M5 build also mostly works.<br> <br><div class="gmail_quote"><br><br>On Fri, Jun 17, 2011 at 11:14 AM, John W. Linville <span dir="ltr"><<a href="mailto:linville@tuxdriver.com">linville@tuxdriver.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I finally got around to rebasing the debloat-testing tree -- I<br>
apologize for the delay!<br>
<br>
There isn't much in it aside from the 3.0-rc3 bits -- dtaht's ath9k<br>
buffer reduction and my (mostly abandoned) skb->destructor-based<br>
eBDP implementation for mac80211. Feel free to nominate<br>
appropriate/interesting patches as you find them (including your own)!<br>
<br>
Thanks,<br>
<br>
John<br>
<font color="#888888">--<br>
John W. Linville Someday the world will need a hero, and you<br>
<a href="mailto:linville@tuxdriver.com">linville@tuxdriver.com</a> might be all we have. Be ready.<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>