Pete Heist <p...@heistp.net> writes: >> On Jan 3, 2019, at 12:03 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >>> Jon, is there anything I can check by instrumenting the code somewhere >>> specific? >> >> Is there any way you could test with a bulk UDP flow? I'm wondering >> whether this is a second-order effect where TCP ACKs are limited in a >> way that cause the imbalance? Are you using ACK compression? > > > Not using ack-filter, if that’s what’s meant by ACK compression. I > thought about the TCP ACK traffic, but would be very surprised if that > amount of ACK traffic could cause that large of an imbalance, although > it’s worth trying to find out. > > I tried iperf3 in UDP mode, but cake is treating these flows > aggressively. I get the impression that cake penalizes flows heavily > that do not respond to congestion control signals. If I pit one 8 TCP > flows against a single UDP flow at 40mbit, the UDP flow goes into a > death spiral with increasing drops over time (iperf3 output attached). > > 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... -Toke _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake