Added notes regarding this test

I am running a continuous stress test now against the SFQ RED,
which I plan to run the rest of the night.

I am dubious of one of the plots. The curve cannot possibly
be that smooth. Can't be. I must have screwed something up.

REDSFQ is doing it's job with a few tweaks (rather than logic,
I just hit it until I started seeing more prob_mark_heads
than dropped)

qdisc mq 1: root
 Sent 64534770811 bytes 43254284 pkt (dropped 77425, overlimits 111717 requeues 160859)
 backlog 47808b 33p requeues 160859
qdisc sfq 10: parent 1:1 limit 300p quantum 1514b depth 127 headdrop divisor 16384
 ewma 3 min 4500b max 18000b probability 0.2 ecn
 prob_mark 0 prob_mark_head 0 prob_drop 0
 forced_mark 0 forced_mark_head 0 forced_drop 0
 Sent 414011 bytes 1406 pkt (dropped 0, overlimits 0 requeues 0)
 rate 120bit 0pps backlog 0b 0p requeues 0
qdisc sfq 20: parent 1:2 limit 300p quantum 1514b depth 127 headdrop divisor 16384
 ewma 3 min 4500b max 18000b probability 0.2 ecn
 prob_mark 0 prob_mark_head 0 prob_drop 0
 forced_mark 0 forced_mark_head 0 forced_drop 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 30: parent 1:3 limit 300p quantum 1514b depth 127 headdrop divisor 16384
 ewma 3 min 4500b max 18000b probability 0.2 ecn
 prob_mark 12 prob_mark_head 99610 prob_drop 0
 forced_mark 0 forced_mark_head 12095 forced_drop 0
 Sent 64534356800 bytes 43252878 pkt (dropped 77425, overlimits 111717 requeues 160859)
 rate 104658Kbit 8763pps backlog 47808b 33p requeues 160859
qdisc sfq 40: parent 1:4 limit 300p quantum 1514b depth 127 headdrop divisor 16384
 ewma 3 min 4500b max 18000b probability 0.2 ecn
 prob_mark 0 prob_mark_head 0 prob_drop 0
 forced_mark 0 forced_mark_head 0 forced_drop 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

src/debloat

@@ -634,7 +634,7 @@ local function efq(parent, handle, speed, flows)
 end
 
 local function efqr(parent, handle, speed, flows)
-   qa(sf("parent %s handle %x: est 1sec 4sec sfq limit 3000 headdrop flows %d divisor 16384 redflowlimit 100000 min 8000 max 60000 probability 0.20 ecn",parent,handle,flows))
+   qa(sf("parent %s handle %x: est 1sec 4sec sfq limit 300 headdrop flows %d divisor 16384 redflowlimit 40000 min 4500 max 18000 probability 0.20 ecn",parent,handle,flows))
 end
 
 function iptables4(...)
@@ -870,7 +870,7 @@ end
 
 local function ethernet_efqr(queues)
 -- FIXME, we can do sane things with speed here
-	 qa("root handle %x: est 1sec 4sec sfq limit 300 headdrop flows %d divisor 16384 redflowlimit 100000 min 8000 max 60000 probability 0.20 ecn",10,150)
+	 qa("root handle %x: est 1sec 4sec sfq limit 300 headdrop flows %d divisor 16384 redflowlimit 70000 min 8000 max 60000 probability 0.20 ecn",10,150)
 end
 
 -- FIXME: just stubs for now

test/newsfqred/README.org

@@ -0,0 +1,27 @@
+* Summary
+
+This was 50 iperf instances, running for 60 seconds
+against a fping -b220 -i 10 -p 10 -C 10000
+- in other words a fairly voip-like sample.
+
+I pulled out the 'start of one test' to look
+at latency under that load and plotted that
+separately as a CDR. Which was nice. Still
+a lot of jitter, but...
+
+* Other observations
+
+During this test (under VERY good conditions)
+
+Typically saw 104-110Mbytes/sec and very even
+performance from 50 iperfs.
+
+No iperf hangs, either.
+
+High quality streams
+
+And lastly... I did this test over ipv6.
+
+* TODO jitter
+* TODO Gather up reference against this kernel combo
+(I did a similar test over ipv4 but not on this kernel)