Re: [PATCH] net_sched: sfq: add optional RED on top of SFQ
From: Dave Taht <hidden>
Date: 2012-01-06 17:36:10
On Fri, Jan 6, 2012 at 6:07 PM, Eric Dumazet [off-list ref] wrote:
Le vendredi 06 janvier 2012 à 17:56 +0100, Dave Taht a écrit :quoted
On Fri, Jan 6, 2012 at 5:31 PM, Eric Dumazet [off-list ref] wrote:quoted
Adds an optional Random Early Detection on each SFQ flow queue.netperf -t TCP_RR is useful -t TCP_MAERTS will be interesting. simultaneous ping?I dont know what you expect from pings, since they are already coming in new flows (unless a ping flood is in effect), so RED doesnt fire for these packets. Same for TCP_RR : Since at most one packet is in flight per flow, RED cannot fire. So there is no differences for them.
Your environment is rather different than mine, and I like having baseline numbers around... but I can live without as I was hovering over the build button in my bql tree, and I'm building now. Up until the world changed, a few days ago, those two did matter when comparing results against QFQ and various combinations of it's sub-qdiscs. I'm at the point now where I have to do cdf plots against large data sets in order to see *anything*, and I'm looking forward to seeing how well this does against wireless, which is really noisy... TCP_MAERTS tests activity in the other direction and (again, your environment is different) does interesting things against byte oriented red, or rather, 'did' when last I checked several eons (months) ago, which was prior to the avqueue fixes. Another excellent test is the 'apache benchmark', ab, while under a saturating load from something else. At some point I'd like to try iobench against nfs and samba, even iscsi against multiple initiators... -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net