[Cerowrt-devel] better ingress shaping somehow
dave.taht at gmail.com
Thu Oct 2 19:07:37 EDT 2014
On Thu, Oct 2, 2014 at 4:54 AM, David Lang <david at lang.hm> wrote:
> On Thu, 2 Oct 2014, Alpha Sparc wrote:
>> How good is the throughput on CeroWrt compared to OpenWrt ?
> The focus of CeroWrt is on reducing latency, not increasing throughput. If
> you run into really badd bufferbloat problems without these scrips, then
> these scripts can result more more 'goodput' (useable data as opposed to
> 'throughput' bits on the wire) getting through, but in the usual case there
> will be a (slight) reduction in the peak throughput.
> This is especially so on the inbound side of things because the router is
> having to work indirectly to throttle the senders so that they don't
> overload the router at the other end of the connection.
> I beleive that on the WNDR3800, it's able to work up to about 50Mb with the
> existing configurations. A faster CPU would do better, a slower one worse.
Actually it appears that cache is very important on fixing inbound rate shaping.
The octeon in the edgerouter lite peaks out at above 60mbits also, but the
bigger, fatter pro product actually manages quite a bit better (with increasing
inaccuracy however). See below...
> The re-write that Dave is talking about is hoting to improve this. From the
> pastebin link Dave listed below, they have it up to ~80Mb now
Oh, no, that's an x86 result. It's barely a blip on that cpu use though, so I am
encouraged so far. Haven't got around to porting it to mips, too many
non-working ideas elsewhere in it, ENOTIME.
But: the real killer, on ingress shaping, is the call to skb_clone in
sch_ingress->act_mirred path, I think.
If it were possible to have sch_cake replace sch_ingress, that would
be a huge win, but following the call path for why that must be cloned
has thus far resisted my archeological expertise. An network ninja
is needed here....
>>> And Jonathon morton has been pouring it all into
>>> pure C - with an integral bandwidth shaper that we
>>> hope will be faster and more efficient than htb.
>>> See an early result:
>>> It takes much of the heavy lifting out of the existing
>>> sqm scripts.
>>> tc qdisc add dev eth1 root cake bandwidth 80mbit
>>> So I don't know where to go. Certainly I'd like to
>>> see the battle hardened sqm scripts (which are more
>>> flexible than the C code above) get more widely used
>>> and in BB.
>>> openwrt users can do that today by adding the ceropackages repo to their
>>> build system.
>>> or just installing the sqm-scripts and luci-app-sqm.
>>> or we can clean it up further for openwrt mainline.
>>> But I haven't seen one core openwrt dev say, yes, we want this mainlined,
>>> here's what you need to fix, so I'm inclined to go back to my cave, get
>>> more sleep, and work on the successor.
More information about the Cerowrt-devel