[Cake] some more fishcake vs everything else tests on 75_10mbit
dave.taht at gmail.com
Sun Jun 7 15:58:13 EDT 2015
as in any live environment, there are anomolies that would have to be
looked at and explaining the data and tests would take longer, so
rather than draw conclusions, ask questions. I look forward to having
a stable testbed again.
toke added a nice new feature to flent to track queue length (both in
bytes and packets), but it can't parse cake as yet, just codel,
fq_codel, and pie (no ecn).
1) still losing on inbound. Once the concatenated queue gets out of
hand, it stays out of hand.
2) peeling at 250us did seem to cut throughput by a bit and latency by
a bit, probably cpu-ish related. ecn led to more latency in some
cases. I like the decision making on a number of flows basis but feel
1ms is too big.
3) count - 2 in the resumption phase was used here also. Seemed long
term stable. somewhere around here i did count/2 but am not sure when
i did. (mental problems with doing tests at 2am. I am trying and
failing to remember where my concern with long term stability came
4) 50 up 1 down (at 10mbit) is "interesting". Compare pie with
fq_codel and cake.
5) a 1gbit cake vs fq on the test box was "interesting". topology here
is client->switch->server. sch_fq on both sides had nearly zero
packets backed up in the qdisc, where cake had 200+. I like the idea
of fiddling with sch_fq to also do more peeling as cake does. Also
there seems to be a latecomer disadvantage happening in sch_fq. I need
to go look at cwnds here...
6) I find myself wanting to fiddle with napi on the box, and dreaming
of fluid models.
What will it take to vastly improve wifi for everyone?
More information about the Cake