> On Nov 24, 2017, at 9:32 PM, Jonathan Morton wrote:
> Mmm, that's a lot of drops. So you're not using ECN?
>
Not using ecn. I did one ecn run but didn’t see much change. I did more runs at
950mbit- 20ms, 50ms 100ms and added a chart at the bottom of rtt vs fairness
> On Nov 24, 2017, at 8:48 PM, Jonathan Morton wrote:
> Can I just point out that the four hardware queues will themselves be
> interfering with the backpressure on short timescales when Cake is in
> unlimited mode, and can easily explain the poorer host-fairness
I support removing metro and below as keywords.
Note: I am more interested in throughput (w/ecn) at the lower rtt
settings than flow fairness (is the aqm scaling?). If we can have
shorter queues overall while not taking a throughput hit, in the
datacenter, that's a win.
I have a hope, however,
On Fri, Nov 24, 2017 at 01:06:12PM +0100, Sebastian Moeller wrote:
>
> > On Nov 24, 2017, at 12:21, Toke Høiland-Jørgensen wrote:
> >
> > Dave Taht writes:
> >
> >> Pete Heist writes:
> >>
> >>>On Nov 23, 2017, at 10:44 AM, Jonathan
Pete Heist writes:
> On Nov 23, 2017, at 10:44 AM, Jonathan Morton
> wrote:
>
> This is most likely an interaction of the AQM with Linux' scheduling
> latency.
>
> At the 'lan' setting, the time comstants are similar in magnitude
> On Nov 23, 2017, at 10:44 AM, Jonathan Morton wrote:
> This is most likely an interaction of the AQM with Linux' scheduling latency.
>
> At the 'lan' setting, the time comstants are similar in magnitude to the
> delays induced by Linux itself, so congestion might be
This is most likely an interaction of the AQM with Linux' scheduling
latency.
At the 'lan' setting, the time comstants are similar in magnitude to the
delays induced by Linux itself, so congestion might be signalled
prematurely. The flows will then become sparse and total throughput
reduced,
It seems that the ‘lan’ keyword (and probably other lower rtt settings in
general) may adversely impact host fairness in some cases. Is this to be
expected? I set up a fairness test with rrul_be_nflows where one client has 2/2
TCP flows and the other has 8/8 TCP flows, then ran five tests: