Hi Dave, so I git around to do the PIE tests...
On Aug 23, 2013, at 07:13 , Dave Taht <dave.t...@gmail.com> wrote: > > > > On Thu, Aug 22, 2013 at 5:52 PM, Sebastian Moeller <moell...@gmx.de> wrote: > Hi List, hi Jesper, > > 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. > 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). > 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? > > 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. > > 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. > > It does. > > `@Dave is there an easy way to find which patches you applied to the kernels > of the cerowrt (testing-)releases? > > 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. > > 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: > > http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/ 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: > > http://lists.alioth.debian.org/pipermail/babel-users/2013-August/001419.html > > I fear it's a comparison gone south, maybe in bradley's optimizations for not > kernel trapping, don't know. > > 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.... > > 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. > > 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). > > 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... > > But, yea, this pie is actually usable, and the previous wasn't. Thank you for > looking at it! > > 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. > > 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. This is as confusing as it is funny…. > The default target is a whopping 20 (rounded to 19), which is in part where > your 70+ms of extra delay came from. > > Multiple parties have the delusion that 20ms is "good enough". It certainly is better than nothing, if the hardware does not allow codel…, but it is not like changing target has that big an effect on RRUL ping RTT: AQM nominal target[ms] estimated ping RTT[ms] down avg good-put[Mbits/s] up avg good-put[Mbits/s] pie 20 110 2.8 0.4 pie 8 100 2.7 0.41 pie 5 90 2.7 0.4 so the target does not have very strong effect on the pie latency... ns2_codel 7 50 3.1 0.39 ns2_codel 3 45 3.1 0.37 fq_codel 7 39 3.1 0.38 fq_codel 3 38 3.15 0.38 Nor does it have a big effect on codel. But latency-wise, I agree, the codels are in a league of their own. And pie sacrifices more down good-put than codel, but seems to retain a bit more of the up good-put. I hope the fraction of routers that can only ever do PIE is not too large, codel looks like the better solution… (I am happy to share my plots but due to email size issues I will not attach them without someone asking) > > Part of the remaining delay may also be rounding error. Cisco uses kernels > with HZ=1000, cero uses HZ=250..... > > 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. > > 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. > > 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. > > 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) > > ... and getting cero stable enough for others to actually use - next up is > fixing the userspace problems. > > ... and trying to make a small dent in the wifi problem along the way (couple > commits coming up) > > ... and find funding to get through the winter. > > 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. > > 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 > :) > > Give pie target 8 and target 5 a shot, please? ns2_codel target 3ms and > target 7ms, too. fq_codel, same.... > > tc -s qdisc show dev ge00 > tc -s qdisc show dev ifb0 > > would be useful info to have in general after each test. So I took these and can post if you are interested. BTW so far I did not bother to save the actual netsurf-wrapper data, all I keep are the plots (as I am somewhat tight on disk space for my day job), since I do not think I will try further analysis on the data (yet). Best Sebastian > > TIA. > > There are also things like tcp_upload and tcp_download and tcp_bidirectional > that are useful tests in the rrul suite. > > 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. > > This is some of the stuff I know that needs fixing in userspace: > > * TODO readlink not found > * TODO netdev user missing > * 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 > * TODO [ 18.480468] Mirror/redirect action on > [ 18.539062] Failed to load ipt action > * upload and download are reversed in aqm > * BCP38 > * Squash CS values > * Replace ntp > * Make ahcp client mode > * Drop more privs for polipo > * upnp > * priv separation > * Review FW rules > * dhcpv6 support > * uci-defaults/make-cert.sh uses a bad path for px5g > * Doesn't configure the web browser either > > > > > Best > Sebastian > > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
