While fiddling with the dslreports "cable" test - (24 full rate flows downstream, oh, my!) I went back to fiddling with policing in addition to sqm. (My take on policing was that at lower rates it sucked but at higher rates it mattered less but was too hard to get the burst size right).
The problem we have with inbound rate limiting and codelling it is that the bandwidth disparity between the ISP and your setting is only a few percentage points - so it remains clearly possible to build up a huge queue at the isp which slowly drains to only slowly be brought back under control by the AQM. You can see this on this spreadsheet, where I was pinging every 10ms to watch what the dslreports test did (and reported as it's statistics. I am happy that what dslreports is reporting is somewhat accurate, as cross checked this way) http://snapon.lab.bufferbloat.net/~cero3/dslreports.xlsx [1] Probably the clearest part of the dataset is the pie tab where you can see the two phases of the dslreports test. Pie does quite well on inbound, policing does better, cake and fq_codel poorly. (24 full rate inbound flows! aggh! can't clear the delay in 10 seconds). (I elided the normal cable drop tail test for those with heart problems, and we still rock on outbound.) Policing as presently defined is a brick wall filter - above the rate, after a burst, drop everything, you don't care about rtt, you just want to shoot packets, there are couple rfcs on it. It has the distinct advantages of occurring no delay or caching in the router, and also being lower cpu. And policers can be improved with some post bufferbloat ideas (see "bobbie" and the linux code is crufty and old). And it looks to be rather effective against tons of flows in slow start, when trying to "fool" the ISP's shaper. #!/bin/sh # set downlink, run sqm, then run this to wipe out the existing downlink # shaper. DOWNLINK=100000 IFACE=eth2 tc qdisc del dev ${IFACE} ingress tc qdisc add dev ${IFACE} handle ffff: ingress tc filter add dev ${IFACE} parent ffff: protocol all u32 match u32 0 0 \ police rate ${DOWNLINK}kbit burst 100k drop flowid :1 # note that the burst parameter is finicy and depends hugely on the # bandwidth and workload. [1] I had asked if I was the only one that used spreadsheets... -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
