On Thu, 2019-12-05 at 10:09 -0800, Ben Greear wrote: > > Hmm, yeah, maybe not then. Something more general in the stack? I just > > can't think of anything. > > Test similar setup 10g wired to 10g wired to make sure traffic generator > can generate hoped for load? Oh, I think it normally works better - I'd have to look up the numbers, don't have them handy now. It's a specific issue to this specific PC that I have, could be related to the (bastardized) kernel that has, or something else. Hence my more general questions how I would understand/debug this, I don't think I can say what the hardware or even kernel is (and even if you knew it'd probably be useless, not sure that's public now.) > > Using chariot. I don't really know it well, just the testers use it. > > So, you have some PC with AX200 in it, acting as station, connected to some AP, > and Charriot runs on that PC and something upstream of the AP and tries to > send traffic from PC to AP? Traffic is going from the DUT to a wired station behind the AP, which actually has two gigabit ethernet links to the AP and two IP addresses, so that we can distribute the wireless load onto two gigabit links. > If you can share the AP model, just possibly we have one and could do a similar > test.... :) I think it's a RT-AX88U. Not sure that really makes a difference. Seems this AP has a bug btw, it's advertising packet extension of 16usec for 20 and 40 MHz, but not for 80 and 160 MHz, which seems a bit odd, and indeed we miss ACK there sometimes. To exclude that as a reason I hacked the driver to always do 16us ignoring the AP information. But I think the issues I outlined with the TXQs are the primary reason for even sending single frames where this would matter ... rather than only A-MPDUs. So I don't *think* it's really related to that, but others are looking at that part (or well, I hope they will be on Sunday, given they're in Israel). In the meantime, I'm stuck trying to figure out why we run the TXQs empty :) johannes
