Dave Taht wrote:
In looking over your test scripts and results, it seems possible you
have gso on.
The driver didn't implement any advanced hardware features, so GSO
was unsupported.
Still, I've found the performance for this SoC is heavily limited by
memory bandwith and implementing
Rick Jones wrote:
On 05/20/2012 08:48 PM, Dave Taht wrote:
Thx for the numbers!
Could you do a TCP_RR while under load from UDP_STREAM?
If you want to generate pretty pictures while doing so, you can
probably tweak
http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh
How
Rick Jones wrote:
On 05/21/2012 02:49 PM, Tobias Diedrich wrote:
Rick Jones wrote:
On 05/20/2012 08:48 PM, Dave Taht wrote:
Thx for the numbers!
Could you do a TCP_RR while under load from UDP_STREAM?
If you want to generate pretty pictures while doing so, you can
probably tweak
In looking over your test scripts and results, it seems possible you
have gso on.
ethtool -K the_device tso off
ethtool -K the_device gso off
ethtool -K the_device ufo off
Secondly, in the 100Mbit and below case, I have found BQL's estimates
to be persistently on the high side, and have
I would really like people to clearly mark when they are using pfifo_fast,
codel, and fq_codel.
Secondly, I note that for utterly best results it is useful to ALSO have
htb on on ingress to a value only slightly lower than the rate under
test, and fq_codel attached to
the bin(s)
(an example of
