Hi List, On Jun 29, 2015, at 18:44 , Dave Taht wrote: > On Mon, Jun 29, 2015 at 6:42 AM, Sebastian Moeller wrote: >> HI Mikael,, hi Jonathan, >> >>> [...] >>> >>> These are the results from 50M and 500M, also including 50up and 50down that I added to my test suite script. >>> >>> http://swm.pp.se/aqm/rrul_150629-cake-4.tar >>> >> >> Now both ingress and egress are up to roughly 455Mbps from roughly 360 with cake just playing leaf qdisc for HTB. This looks even better than before… > > 350 *usec* induced delay on the 50mbit rrul_be test. w00t! > > Most of the tests compare well with the reference rangeley data now. I > would like a 900mbit soft shaped result. Make sure to use the correct per packet overhead of 18 + 20, on gigabit ethernet inter-frame gap and preamble cost 20 Bytes worth of data. So with a MTU of 1500 thee is no issue (900 * (1538/1518) = 911.85770751 Mbps) but the smaller the packets get: 900 * (MTU+38/MTU+18) = 1000 (MTU+38/MTU+18) = (1000 / 900) MTU+38 = (10 / 9) * (MTU + 18) MTU + 38 = (10/9) * MTU + (10/9)*18 38 - (10/9)*18 = (10/9) * MTU - (9/9)MTU 38 - (10/9)*18 = (1/9) MTU MTU = (38 - ((10/9)*18))*9 = 162 So for TCP/IPv4 MSS < 122 the shaper will not keep the ethernet hardware queues empty… On the other hand shaping at 1000/(88/64) = 727.272727273 Mbps should make sure that even at minimal packet size of 64byte shaping would still be keeping the ethernet queues “empty-ish”. If the 1200ac can shape at 900 I would rather specify the correct overhead though. To make things a bit trickier, depending on the interface used the kernel will already account for the standards ethernet header without the frame check sequence, so I would guess in the 900Mbps soft shaper on ethN scenario one would need to add a per packet overhead of 24 bytes. If someone in the know could double check that reasoning I would be much obliged… Best Regards Sebastian > > 1.2ms at 500mbit. Less of a w00t. Possible it is coming from elsewhere > on that path (fq or fq_codel on the server and client?) > > cake currently peels at 1ms / flows (more or less)... NAPI is an > issue... hw mq an issue... > > There are a half dozen things in the mvneta driver I would try to > reduce it's latency more. The easy ones: > > reduce this to 16: > > netif_napi_add(dev, &pp->napi, mvneta_poll, NAPI_POLL_WEIGHT); > > Reduce this to 24: (this will also reduce the max outstanding stuff in > the driver by a LOT, but is still not BQL!) > > /* Max number of allowed TCP segments for software TSO */ > #define MVNETA_MAX_TSO_SEGS 100 > > Both of the will improve read side latency at the cost of more sirqs. > > I do not know what reducing these will do, and would test both of the > above separately. > > /* Coalescing */ > #define MVNETA_TXDONE_COAL_PKTS 1 > #define MVNETA_RX_COAL_PKTS 32 > #define MVNETA_RX_COAL_USEC 100 > > As for cake itself, eric dumazet told us we dont need atomic ops in it, > and peeling at at even lower threshold has some appeal (to me, anyway) > > attached is a patch for that, put it in your feeds/cero/kmod_sched_cake/patches > directory, rebuild (make package/kmod-sched-cake/{clean,compile,install}) > > (bump up the makefile rel number also, if you want) > > > > > >> Best Regards >> Sebastian >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave Täht > worldwide bufferbloat report: > http://www.dslreports.com/speedtest/results/bufferbloat > And: > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast