On Apr 16, 2018, at 11:23 PM, Toke Høiland-Jørgensen <
toke@toke.dk> wrote:
I remember that fairness behavior at low RTTs (< 20ms) needed to be
either improved or documented, and don’t see anything about that in
the man page in the tc-adv repo thus far. Summarizing the host
isolation results at
http://www.drhleny.cz/bufferbloat/cake/round2/#hostiso_cake_{rtt}_{qos-id}
<http://www.drhleny.cz/bufferbloat/cake/round2/#hostiso_cake_%7Brtt%7D_%7Bqos-id%7D>:
RTT: fairness (1.0 == perfect fairness)
---
100us: 2.22
1ms: 1.7
2ms: 1.6
3ms: 1.42
5ms: 1.31
8ms: 1.16
10ms: 1.12
20ms: 1.02
40ms: 1.017
Erm, what's the metric and which data source are you looking at here?
Subject changed...
The clients were as follows:
Client 0- 1 stream up
Client 1- 12 streams up
Client 2- 1 stream down
Client 3- 12 streams down
It looks like what I used before was Client 3’s “TCP Download Sum avg” divided by Client 2’s “TCP Download avg” from the srchost/dsthost tests. The data’s in a table here (see column “Client 3 Mean / Client 2 Mean”):
I was calculating by hand before, so the numbers are slightly different, but that’s the idea.
Now, these tests were done at 500Mbit between two cabled APU2s, so we could just be running out of CPU on this hardware at lower RTTs. There are CPU stats included, and a “Flent Data Files” section. Is it possible to tell from this if CPU is the problem? The highest median client load I see looks to be 0.77 for the 40ms tests, for example, with a mean of 0.63.
If we’re not sure, the tests would have to be redone at a lower bitrate. It would probably be best if someone reproduced these results externally anyway, and perhaps it would also be better to not be mixing upload and download tests at the same time… :)