Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Pete Heist <pete@heistp.net>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] dual-src/dsthost unfairness, only with bi-directional traffic
Date: Thu, 3 Jan 2019 17:35:14 +0100	[thread overview]
Message-ID: <316524A2-FEB5-46DC-AC96-4E1AED27695A@heistp.net> (raw)
In-Reply-To: <87ftu9yj1n.fsf@toke.dk>


> On Jan 3, 2019, at 2:20 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Pete Heist <pete@heistp.net> writes:
> 
>> I’m not sure there’d be any way I can test fairness with iperf3 in UDP
>> mode. We’d need something that has some congestion control feedback,
>> right? Otherwise, I don’t think there are any rates I can choose to
>> both reach saturation and not be severely punished. And if it has
>> congestion control feedback, it has the ACK-like traffic we’re trying
>> to avoid for the test. :)
> 
> Try setting cake to 'interplanetary' - that should basically turn off
> the AQM dropping...

Ok, so long as we know that we’re not testing any possible interactions between AQM and host fairness, but we may learn more from it anyway. I’m using my client to server rig here (two APU2s on kernel 4.9.0-8), not the APU1 one-armed router middle box.

So, basic single client rig tests (OK):

	IP1 8-flow TCP up: 95.8
	IP2 1-flow 48mbit UDP up: 48.0 (0% loss)
	IP1 8-flow x 6mbit/flow = 48mbit UDP down: 48.0 (0% loss)
	IP2 1-flow TCP down: 96.0

Competition up (OK):

	IP1 8-flow TCP up: 59.5
	IP2 1-flow 48mbit UDP up: 36.7 (0% loss)
		Note: I don’t know why the UDP send rate slowed down here. It’s probably not the CPU, as it occurs at lower rates also. I’ll forge on.

Competition down (not OK, high UDP loss):

	IP1 1-flow TCP down: 53.3
	IP2 8-flow x 6mbit/flow 48mbit UDP down: 8.6 (82% loss)
		Note: I have no idea what happened with the UDP loss rate here, so I’ll go back to a single IP1 UDP test.

Back to single client (weird, still seeing loss):

	IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (5.6% loss)

Ok, I know that was working with no loss before. Stop and restart cake, then (loss stops after restart):

	IP2 8-flow x 6mbit/flow 48mbit UDP down: 48.0 (0% loss)

That’s better, now stop and restart cake and try the "competition down" test again (second trial):

	IP1 1-flow TCP down: 55.3
	IP2 8-flow x 6mbit/flow 48mbit UDP down: 5.8 (88% loss)
		Note: I have no idea what happened with the UDP loss rate here, so I’ll go back to a single IP1 UDP test.

Since this rig hasn’t passed the two-host uni-directional test because of the high loss rate on the “competition down” test, I’m not going to go any further. I’ll rather go back to my one-armed router rig and send those results in a separate email.

However, I consider it strange that I still see UDP loss after the "competition down” test has run and is completed, then it stops happening after restarting cake. That’s another issue I don’t have time to explore at the moment, unless someone has a good idea of what’s going on there.


  reply	other threads:[~2019-01-03 16:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01 23:04 Pete Heist
2019-01-03  3:57 ` Georgios Amanakis
2019-01-03  4:15   ` Georgios Amanakis
2019-01-03  5:18     ` Jonathan Morton
2019-01-03 10:46       ` Pete Heist
2019-01-03 11:03         ` Toke Høiland-Jørgensen
2019-01-03 13:02           ` Pete Heist
2019-01-03 13:20             ` Toke Høiland-Jørgensen
2019-01-03 16:35               ` Pete Heist [this message]
2019-01-03 18:24                 ` Georgios Amanakis
2019-01-03 22:06                 ` Pete Heist
2019-01-04  2:08                   ` Georgios Amanakis
2019-01-04  8:09                     ` Pete Heist
2019-01-04  7:37                   ` Pete Heist
2019-01-04 11:34             ` Pete Heist
2019-01-15 19:22               ` George Amanakis
2019-01-15 22:42                 ` Georgios Amanakis
2019-01-16  3:34                   ` George Amanakis
2019-01-16  3:47                     ` gamanakis
2019-01-16  7:58                       ` Pete Heist
2019-01-26  7:35                       ` Pete Heist
2019-01-28  1:34                         ` Georgios Amanakis
2019-01-18 10:06                     ` Toke Høiland-Jørgensen
2019-01-18 12:07                       ` Georgios Amanakis
2019-01-18 13:33                         ` Toke Høiland-Jørgensen
2019-01-18 13:40                           ` Sebastian Moeller
2019-01-18 14:30                             ` Toke Høiland-Jørgensen
2019-01-18 13:45                           ` Jonathan Morton
2019-01-18 14:32                             ` Toke Høiland-Jørgensen

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=316524A2-FEB5-46DC-AC96-4E1AED27695A@heistp.net \
    --to=pete@heistp.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=toke@toke.dk \
    /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