<html><head></head><body>Maybe you can do a quick blog howto? I'd bet the same could be done for raspberry pi and perhaps my other toy the wandboard which has a gigE adapter and Scsi making it a nice iscsi target or nfs server. <br>
<br>
De bloating the world... One step at a time.<br><br><div class="gmail_quote">On Jun 11, 2014, Dave Taht <dave.taht@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k10mail">The bloat problem and solutions are not just limited to fixing<br />routers, but hosts.<br /><br />Nearly every low end board I've seen out there forgos a gigE ethernet<br />interface in favor of a lower power and cost 100mbit interface.<br /><br />No distro I've seen modifies the default pfifo txqueuelen from the<br />current 1000 packet default down to a more reasonable 100 packet<br />default in that case. And, while many ethernet devices in this<br />category are hooked up via usb (and currently hard to add BQL support<br />to), some are not, and byte queue limit support can be easily added to<br />those.<br /><br />Sadly byte queue limits (BQL) is only implemented on a bunch of top<br />end ethernet drivers. (about 10, last I looked)<br /><br />I needed a break from big problems, so a couple late nights later, I<br />have a very small patch adding support for BQL to the beaglebone<br />black:<br /><br /><a
href="http://snapon.lab.bufferbloat.net/~d/0001-Add-BQL-support-to-cpsw-beaglebone-driver.patch">http://snapon.lab.bufferbloat.net/~d/0001-Add-BQL-support-to-cpsw-beaglebone-driver.patch</a><br /><br />And the results were quite pleasing at 100mbit. BQL holds things down<br />to two full size packets in the tx ring and we see an enormous<br />improvement in bidirectional throughput, jitter, and latency.<br /><br /><a href="http://snapon.lab.bufferbloat.net/~d/beagle_bql/bql_makes_a_difference.png">http://snapon.lab.bufferbloat.net/~d/beagle_bql/bql_makes_a_difference.png</a><br /><a href="http://snapon.lab.bufferbloat.net/~d/beagle_bql/beaglebonewins.png">http://snapon.lab.bufferbloat.net/~d/beagle_bql/beaglebonewins.png</a><br /><br />The default linux behavior ( pfifo fast, txqueue 1000 ) prior to this<br />patch looked pretty awful:<br /><br /><a
href="http://snapon.lab.bufferbloat.net/~d/beagle_nobql/pfifo_nobql_tsq3028txqueue1000.svg">http://snapon.lab.bufferbloat.net/~d/beagle_nobql/pfifo_nobql_tsq3028txqueue1000.svg</a><br /><br />and went to looking like this:<br /><br /><a href="http://snapon.lab.bufferbloat.net/~d/beagle_bql/pfifo_bql_tsq3028txqueue1000.svg">http://snapon.lab.bufferbloat.net/~d/beagle_bql/pfifo_bql_tsq3028txqueue1000.svg</a><br /><br />And adding the new fq scheduler looked like this:<br /><br /><a href="http://snapon.lab.bufferbloat.net/~d/beagle_bql/fq_bql_tsq3028.svg">http://snapon.lab.bufferbloat.net/~d/beagle_bql/fq_bql_tsq3028.svg</a><br /><br />(fq_codel was similar)<br /><br />The fact that we don't achieve full upload throughput on this last<br />test is probably<br />due to having a tail dropping switch in the way, and/or some dma dequeuing<br />cleanup conflicts between the low level transmit and receive queues on<br />this device (they share an interrupt AND use napi which seems<br
/>puzzling).<br /><br />But any day I can get a 4-10x improvement in latency and throughput is<br />a good day. One IoT device down, thousands to go. It would be nice if<br />the chipmakers were incorporating bql into boxes destined for the<br />internet of things.<br /></pre></blockquote></div><br/>-- Sent from my Android device with <b><a href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@ Mail</a></b>. Please excuse my brevity.</body></html>