[Cerowrt-devel] [Cake] documentation review request and out of tree cake builds for openwrt/etc.

[Dave Taht]

On Tue, Apr 28, 2015 at 1:52 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> An integral shaper (that can be on or off or tuned dynamically)
>> ---
>> is much "tighter" than htb - works on current low end hardware without
>> running out of cpu. See attached graphs.
>
> This seems to imply that "tighter" means "uses less CPU". In fact they are
> two separate benefits; "tighter" means "bursts less".

OK, will fix.

> Also, what graphs?

I did not put them up because I was fiddling with the dslreports test
at the same time as a rrul test and I got a result that I do not
understand.

http://snapon.lab.bufferbloat.net/~d/dsl/vsdslreports_at_the_sametime.png

(cake and pie results in the same dir, unplotted)

dslreports test result: http://www.dslreports.com/speedtest/384651

I have not fully internalized what a 10x1 ratio of down to up
bandwidth "looks like" - where a full download stream would basically
fill half the uplink with acks (every other ack) or the whole thing
(on tcp's acking on every packet), and I have internalized that aqms
have little effect on pure ack traffic... but....

What I had expected to see was about a 2ms (tops!) further increase in
measured inbound latency here. A single full mtu packet at 100Mbit is
130us, and I was under the impression the dslreports cable test was 16
inbound flows, so 130us * 16 = 2ms. The number of acks in flight
should have been constant, but got a great deal more service time, but
that is not evident from the uplink...

Where is the extra latency coming from at T+50? It is repeatable no
matter the inbound qdisc (tried pie, fq_codel, cake) This bump from 4
flows to 20 should ultimately have been handled, AND with FQ in place,
the measure at 100mbit should actually have stayed pretty flat, just
as it did for outbound. Instead, 10ms is added.

A) I have generally worried about the effects of pacing on packet
aggregation in cable modems, etc. HTB is doing a bit of pacing that
might be affecting media access opportunities here, and/or we are
running out of room to wedge acks into an aggregate.
B) Also DRR tends to release bunches of acks per TCP flow which in
turn releases a bunch in response...
C) NAPI?
D) Servicing tons of acks eats cpu
E) Something else?

Ah, well, I guess I gotta go try a test on ethernet at the same rates
and setup, and fiddle with owamp...

The topology here was:

OSX - wifi          - rangeley box - cablemodem - internet
Linux - ethernet - rangeley box

>
> As for installing kernel headers, on Debian based distros the right package
> should be linux-headers-`uname -r` .
>
> - Jonathan Morton



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67