@kong is testing the nss offloads here.
flent --step-size=.05 --socket-stats --te=upload_streams=4 tcp_nup -H [netperf-eu.bufferbloat.net](http://netperf-eu.bufferbloat.net/)
flent --step-size=.05 --socket-stats --te=download_streams=4 tcp_ndown -H [netperf-eu.bufferbloat.net](http://netperf-eu.bufferbloat.net/)
ISP speed is ~100Mbps/35Mbps. I have configured 95000 down and 30000 up.
--socket-stats only works on the up. Both the up and down look ok, however the distribution of tcp RTT looks a bit off. These lines should be pretty identical.
Three possible causes: 1) your overlarge burst parameter. At 35Mbit you shouldn't need more than 8k!! The last flow has started up late and doesn't quite get back into fairness with the others. 2) They aren't using a DRR++ scheduler, but DRR. 3) Unknown. I always leave a spot in there for the unknown and without a 35ms rtt path to compare this against I just go and ask you for more data
No need for more down tests at the moment.
A) try 8 and 16 streams on the up.
B) try a vastly reduced htb burst.
A packet capture of a simple 1 stream test also helps me on both up and down, if you are in a position to take one. I don't need a long one (use -l 20) and tcpdump -i the_interface -s 128 -w whatever.cap on either the server or client will suffice.
I am temporarily relieved, it's just that the drop scheduler in the paper was too agressive above 100mbit... and we haven't tested that on this hardware....
Anyway this more clearly shows two of the flows are "stuck":
The 100mbit download is just perfect - no synchronization, perfect throughput, 5ms of latency.