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 <[email protected]> > >> > >> 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 > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
