On Tue, Apr 28, 2015 at 1:52 PM, Jonathan Morton <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
