In my previous test the clients communicated to different flent servers (flent-newark, flent-newark.bufferbloat.net). Iproute2 was iproute2-ss4.18.0-4-openwrt. I will try to test on latest 4.20, will take some time though.
I have the feeling we have discussed a similar issue in the past (https://lists.bufferbloat.net/pipermail/cake/2017-November/002985.html). I understand what Jonathan says. However I cannot explain why *without* bidirectional traffic the "dual- host" mode behaves like "src/dst-host", but *with* bidirectional traffic it behaves like "triple-isolate". The cake instances on the two interfaces are separate, right? So what happens on one interface should not influence the other. Even with bidirectional traffic the "dual- host" mode should still behave like the "src/dst-host" mode in terms of host fairness, or not? At least this is what I would intuitively expect. On Thu, Jan 3, 2019 at 11:35 AM Pete Heist <p...@heistp.net> wrote: > > > > On Jan 3, 2019, at 2:20 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > > > Pete Heist <p...@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. > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
