<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 5:52 PM, Sebastian Moeller <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi List, hi Jesper,<br>
<br>
So I tested 3.10.9-1 to assess the status of the HTB atm link layer adjustments to see whether the recent changes resurrected this feature.<br>
<div class="im"> Unfortunately the htb_private link layer adjustments still is broken (RRUL ping RTT against Toke's netperf host in Germany of ~80ms, same as without link layer adjustments). On the bright side the tc_stab method still works as well as before (ping RTT around 40ms).<br>
I would like to humbly propose to use the tc stab method in cerowrt to perform ATM link layer adjustments as default. To repeat myself, simply telling the kernel a lie about the packet size seems more robust than fudging HTB's rate tables. Especially since the kernel already fudges the packet size to account for the ethernet header and then some, so this path should receive more scrutiny by virtue of having more users?<br>
</div></blockquote><div><br></div><div>It's my hope that the atm code works but is misconfigured. You can output the tc commands by overriding the TC variable with TC="echo tc" and paste here.<br> <br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
</div> Now, I have been testing this using Dave's most recent cerowrt alpha version with a 3.10.9 kernel on mips hardware, I think this kernel should contain all htb fixes including commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling) but am not fully sure.<br>
</blockquote><div><br></div><div>It does. <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
`@Dave is there an easy way to find which patches you applied to the kernels of the cerowrt (testing-)releases? </blockquote><div><br></div><div>Normally I DO commit stuff that is in testing, but my big push this time around was to get everything important into mainline 3.10, as it will be the "stable" release for a good long time. <br>
<br></div><div>So I am still mostly working the x86 side at the moment. I WAS kind of hoping that everything I just landed would make it up to 3.10. But for your perusal:<br><br><a href="http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/">http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/</a> has most of the kernel patches I used in it. 3.10.9-2 has the ipv6subtrees patch ripped out due to another weird bug I'm looking at. (It also has support for ipv6 nat thx to the ever prolific stephen walker heeding the call for patches...). 100% totally untested, I have this weird bug to figure out how to fix next:<br>
</div><div><br><a href="http://lists.alioth.debian.org/pipermail/babel-users/2013-August/001419.html">http://lists.alioth.debian.org/pipermail/babel-users/2013-August/001419.html</a><br><br></div><div>I fear it's a comparison gone south, maybe in bradley's optimizations for not kernel trapping, don't know.<br>
<br></div><div>3.10.9-2 also disables dnsmasq's dhcpv6 in favor of 6relayd. I HATE losing the close naming integration, but, had to try this....<br><br></div><div>If you guys want me to start committing and pushing patches again, I'll do it, but most of that stuff will end up in 3.10.10, I think, in a couple days. The rest might make 3.12. Pie has to survive scrutiny on the netdev list in particular.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While I have you r attention :) I also tested 3.10.9-1's pie and it is way better than 3.10.6-1's (RRUL ping RTTs around 110 ms instead of 3000ms) but still worse than fq_codel (ping RTTs around 40ms with proper atm link layer adjustments).<br>
</blockquote><div><br></div><div>This is with simple.qos I imagine? Simplest should do better than that with pie. Judging from how its estimator works I think it will do badly with multiple queues. But testing will tell...<br>
<br>But, yea, this pie is actually usable, and the previous wasn't. Thank you for looking at it!<br><br></div><div>It is different from cisco's last pie drop in that it can do ecn, does local congestion notification, has a better use of net_random, it's mostly KernelStyle, and I forget what else.<br>
<br></div><div>There is still a major rounding error in the code, and I'd like cisco to fix the api so it uses identical syntax to codel. Right now you specify "target 8" to get "target 7", and the "ms" is implied. target 5 becomes target 3. The default target is a whopping 20 (rounded to 19), which is in part where your 70+ms of extra delay came from. <br>
<br></div><div>Multiple parties have the delusion that 20ms is "good enough".<br><br></div><div>Part of the remaining delay may also be rounding error. Cisco uses kernels with HZ=1000, cero uses HZ=250.....<br><br>
</div><div>Anyway, to get more comparable tests... you can fiddle with the two $QDISC lines in simple*.qos to add a target 8 to get closer to a codel 5ms config, but that would break a codel config which treats target 8 as target 8us.<br>
<br></div><div>I MIGHT, if I get energetic enough, fix the API, the time accounting, and a few other things in pie, the problem is, that ns2_codel seems still more effective on most workloads and *fq_codel smokes absolutely everything. There are a few places where pie is a win over straight codel, notably on packet floods. And it may well be easier to retrofit into existing hardware fast path designs. <br>
<br>I worry about interactions between pie and other stuff. It seems inevitable at this point that some form of pie will be widely deployed, and I simply haven't tried enough traffic types and RTTs to draw a firm conclusion, period. Long RTTs are the last big place where codel and pie and fq_codel have to be seriously tested. <br>
</div><div><br>ns2_codel is looking pretty good now, at the shorter RTTs I've tried. A big problem I have is getting decent long RTT emulation out of netem (some preliminary code is up at github) <br><br></div><div>... and getting cero stable enough for others to actually use - next up is fixing the userspace problems. <br>
<br></div><div>... and trying to make a small dent in the wifi problem along the way (couple commits coming up)<br><br></div><div>... and find funding to get through the winter.<br></div><div> <br></div><div>There's probably a few other things that are on that list but I forget. Oh, yea, since the aqm wg was voted on to be formed, I decided I could quit smoking.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
While I am not able to build kernels, it seems that I am able to quickly test whether link layer adjustments work or not. SO aim happy to help where I can :)<br></blockquote><div><br></div><div>Give pie target 8 and target 5 a shot, please? ns2_codel target 3ms and target 7ms, too. fq_codel, same....<br>
<br></div><div>tc -s qdisc show dev ge00<br>tc -s qdisc show dev ifb0<br><br></div><div>would be useful info to have in general after each test.<br><br>TIA.<br><br></div><div>There are also things like tcp_upload and tcp_download and tcp_bidirectional that are useful tests in the rrul suite.<br>
<br></div><div>Thank you for your efforts on these early alpha releases. I hope things will stablize more soon, and I'll fold your aqm stuff into my next attempt this weekend.<br><br></div><div>This is some of the stuff I know that needs fixing in userspace:<br>
<br>* TODO readlink not found<br>* TODO netdev user missing<br>* TODO Wed Dec 5 17:14:46 2012 authpriv.error dnsmasq: found already running DHCP-server on interface 'se00' refusing to start, use 'option force 1' to override<br>
* TODO [ 18.480468] Mirror/redirect action on<br>[ 18.539062] Failed to load ipt action<br>* upload and download are reversed in aqm<br>* BCP38<br>* Squash CS values<br>* Replace ntp<br>* Make ahcp client mode<br>* Drop more privs for polipo<br>
* upnp<br>* priv separation<br>* Review FW rules<br>* dhcpv6 support<br>* uci-defaults/make-cert.sh uses a bad path for px5g<br>* Doesn't configure the web browser either<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Best<br>
<span class=""><font color="#888888"> Sebastian<br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>
</div></div>