On Mon, Oct 01, 2012 at 10:44:56AM -0700, Sebastian Moeller wrote:
Hi Felix,
On Oct 1, 2012, at 10:26 , Felix Fietkau wrote:
On 2012-10-01 6:49 PM, Dave Täht wrote:
From: Dave Taht dave.t...@bufferbloat.net
After queue lengths start getting out of hand, try to preserve memory
by shortening skbs to their truesize on the common pfifo, codel, and
fq_codel qdiscs.
Arguably (128) should be a configureable param
I think this is a bad idea, at least on routers. 'Preserving memory'
here involves copying buffer data, which is really horrible for
performance. The memory bus is a tough bottleneck when routing at high
speed…
But the in severe situations the alternative is OOM - watchdog based
reboot; under these circumstances limping along and recover later once the
memory pressure is over sounds better than rebooting? (At least in cerowrt
the OOM reboot cycle could be easily initiated by a simple UDP flood through
the router. Now, while this is abusive, it is way better if the router
survives this and recovers with out a reboot, IMHO). This change along with a
few others Dave made turned cerowrt robust against UDP flooding which I think
is the right thing to do. Since this only triggers once memory gets scarce,
think of this as a defense mechanism in a situation where performance will
suffer anyway...
best
Sebastian
As I noted, openwrt's workaround of a txqueuelen of 30 on wifi means this
check will never be hit. It also means that fq_codel can't be applied at
all to the openwrt wifi queues, as 30 is not deep enough to do any good.
(cerowrt is presently using a latency/bandwidth compromise of a shortened
driver queue and a longer fq_codel based txqueue - and we're painfully
aware that far more work is needed to make wireless-n stop being so
darn bloated and unresponsive:
http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless )
So, it IS possible to run a box with tons of SSIDs easily out of memory
with the larger txqueuelens cero is using, and this patch helped that.
Other devices (such as ethernet and qos'd devices)
have longer queues by default, where this memory saving optimization
*might* help
It would be interesting if more folk would abuse their openwrt routers
heavily using the current (2.6) version of netperf, to fully exercise
the 4 hardware wifi queues, or the multiple qos queues.
Tests like this showed up a hw queue bug in ath9k (long since
fixed) and appears to mess up iwl (on a laptop) somewhat, and it would
be good to blow up more drivers and devices... in addition to running
older versions of openwrt out of memory.
What I typically do is a bunch of udp flooding and tcp flooding,
along the lines of this, using the netperf 2.6 distro, and exercising
each hw queue thusly.
# netserver runs here
SERVER1=somewhere
SERVER2=somewhere.else
DUR=120
# on clients connected through the router via
# wifi, etc
(
# Flood BE with tcp in both directions
netperf -l$DIR -H$SERVER1 -tTCP_MAERTS
netperf -l$DIR -H$SERVER2 -tTCP_MAERTS
netperf -l$DIR -H$SERVER1 -tTCP_STREAM
netperf -l$DIR -H$SERVER2 -tTCP_STREAM
# Beat up on the BK, BE, VO, VI hw queues
netperf -l$DIR -Y CS1,CS1 -H$SERVER2 -tUDP_STREAM
netperf -l$DIR -Y CS0,CS0 -H$SERVER2 -tUDP_STREAM
netperf -l$DIR -Y EF,EF -H$SERVER2 -tUDP_STREAM
netperf -l$DIR -Y CS5,CS5 -H$SERVER2 -tUDP_STREAM
)
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
