Now that I'm done travelling...<br><br> I've been building up my lab a bit to (as one example) do far more complete netem delay and loss based testing of web and voip traffic under load, in addition to the rrul work. <br>
<br>I am very interested as to suggestions as to what and how to evaluate various loads. I've already added emulations of two of cisco's tests from their pie paper, and have come up with a way to do the rest...<br>
<br>Currently I'm stuck: as the atom based motherboard I'd chosen has a totally non-functional GM500 video chip in it. It does have decent e1000e ethernet on board, and a slot where I stuck another e1000e based network card - and I'm trying to create equivalent setups for cerowrt and the atom boxes for comparison. I ran into all sorts of old problems like GRO offloads, etc, but I'm gradually beating the bugs down while I look for another cheap-but-good board to stack 4-6 of in the rack. (suggestions for a good board to use welcomed. I also have some common hardware like raspberri pi, beagleboard black, and smileplug on order, in addition to a couple android devices, and a few new router candidates, all of which will start arriving next week)<br>
<br>Anyway, there are some extremely early results up at: <a href="http://snapon.lab.bufferbloat.net/~d/delay/">http://snapon.lab.bufferbloat.net/~d/delay/</a> <br><br>on my conventional 20Mbit/4Mbit down/up model, complete with the ubuntu 13.4 kernel build and kernel patches I used, the shaper code is at <a href="https://github.com/dtaht/ceropackages-3.3/tree/master/net/aqm-scripts/files/usr/lib/aqm">https://github.com/dtaht/ceropackages-3.3/tree/master/net/aqm-scripts/files/usr/lib/aqm</a> (use the debloat script to kill the offloads)<br>
<br>and now (darn it) I'm going back to trying to vacation in the hope some more folk will take a look at the kernel, patches, etc, etc.<br><br><a href="http://snapon.lab.bufferbloat.net/~d/delay/delay100-pie.svg">http://snapon.lab.bufferbloat.net/~d/delay/delay100-pie.svg</a><br>
<br>Pie code not thoroughly validated yet.<br><br><a href="http://snapon.lab.bufferbloat.net/~d/delay/delay100-codel.svg">http://snapon.lab.bufferbloat.net/~d/delay/delay100-codel.svg</a><br><br>The current linux codel<br>
<br><a href="http://snapon.lab.bufferbloat.net/~d/delay/delay100-ns2_codel.svg">http://snapon.lab.bufferbloat.net/~d/delay/delay100-ns2_codel.svg</a><br><br>The advanced ns2 codel model<br><br><a href="http://snapon.lab.bufferbloat.net/~d/delay/delay100-sfq.svg">http://snapon.lab.bufferbloat.net/~d/delay/delay100-sfq.svg</a><br>
<br>(this shows that sfq's default buffer depth is too short at these RTTs and speeds)<br><br><a href="http://snapon.lab.bufferbloat.net/~d/delay/delay100-nfq_codel.svg">http://snapon.lab.bufferbloat.net/~d/delay/delay100-nfq_codel.svg</a><br>
<br>fq_codel using ns2's model of codel<br><br>While validating the new hardware I also worked on some direct p2p stuff between two machines at 10 and 100Mbit line rates:<br><br><a href="http://snapon.lab.bufferbloat.net/~d/pie/10mbit-direct-10-capture/">http://snapon.lab.bufferbloat.net/~d/pie/10mbit-direct-10-capture/</a> <br>
<br>I would be incredibly hesitant to draw any conclusions from any of the above, much validation (with a fresh brain needed in my case) remains to be done on the hardware and patches. I would welcome more eyeballs on the pie patches in particular.<br>
<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>