From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Pete Heist <pete@eventide.io>, Jonathan Morton <chromatix99@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] net-next is OPEN...
Date: Fri, 20 Apr 2018 11:32:55 +0200 [thread overview]
Message-ID: <87zi1yxlx4.fsf@toke.dk> (raw)
In-Reply-To: <6D78919D-C4F0-4EC6-A9D4-BA81EEAC334D@eventide.io>
Pete Heist <pete@eventide.io> writes:
>> On Apr 18, 2018, at 7:43 AM, Pete Heist <pete@eventide.io> wrote:
>>
>> I also think I saw this happen at lower bandwidths as well, when the CPU wasn’t loaded. What I’ll do is re-test on the current version I have at, say, 50Mbit (or to where load drops substantially), then update to the head and test again, and let you know...
>>
>>> On Apr 17, 2018, at 3:52 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>
>>>> On 16 Apr, 2018, at 11:55 pm, Pete Heist <pete@eventide.io> wrote:
>>>>
>>>> I remember that fairness behavior at low RTTs (< 20ms) needed to be either improved or documented
>>>
>>> The reason for the behaviour, IIRC, was that throughput dropped below 100% when the latency target was reduced too much. Since then there has been a small change which might improve it a little, so a retest would be reasonable.
>
> At 50mbit I don’t see nearly as much fairness degradation at low RTTs, although there’s some. Even at 100us, “fairness” is around 1.1 (1.0 being perfectly fair) instead of the 2.x I saw at 500mbit. I do not see much of a difference between the latest code (16d7fed, 2018-04-17) and the previous code I tested (7061401, 2017-12-01), if that info is of use.
>
> RTT: tcp_1up upload Mbps / tcp_12up upload Mbps
>
> 7061401 (2017-12-01):
>
> 100us: 23.80 / 25.85
> 1ms: 23.89 / 29.46
> 10ms: 23.93 / 24.66
> 40ms: 23.96 / 24.10
> 100ms: 23.97 / 24.12
>
> 16d7fed (2018-04-17):
>
> 100us: 23.97 / 26.49
> 1ms: 23.89 / 26.27
> 10ms: 23.98 / 26.37
> 40ms: 23.94 / 24.08
> 100ms: 23.97 / 24.12
>
> I can post reports / flent files on request.
>
> So it appears this is CPU related, and not worth exploring further(?)
> and not worth documenting(?) other than that once things have
> stabilized, documenting how Cake degrades under various extreme
> conditions would be informative.
Awesome, thanks for re-testing! :)
-Toke
next prev parent reply other threads:[~2018-04-20 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180416.110000.1863692416063182988.davem@davemloft.net>
2018-04-16 15:01 ` [Cake] Fwd: " Dave Taht
2018-04-16 15:12 ` Toke Høiland-Jørgensen
2018-04-16 20:55 ` [Cake] " Pete Heist
2018-04-16 21:23 ` Toke Høiland-Jørgensen
2018-04-17 2:45 ` [Cake] fairness vs RTT Pete Heist
2018-04-17 8:24 ` Toke Høiland-Jørgensen
2018-04-17 13:52 ` [Cake] net-next is OPEN Jonathan Morton
2018-04-18 5:43 ` Pete Heist
2018-04-19 21:17 ` Pete Heist
2018-04-20 9:32 ` Toke Høiland-Jørgensen [this message]
2017-12-01 14:52 [Cake] net-next is open Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zi1yxlx4.fsf@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=pete@eventide.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox