On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote: > Been running this for about 24 hours on my x395, seems to be good. > > Had only one stuck wifi when first trying it, but I was also stuck on a > 2.4GHz channel and live in a dense apartment building. Forcing it to > move to a 5GHz channel fixed it all up, and no problems since then.
Understanding situations where it doesn't work is actually quite important. Is it repeatable? And how big is the impact? If you can fly somewhat in Minecraft on 2 GHz, and if it consistently recovers after stuttering, I'd consider that success. This is a huge change for the device you are using; all the Rx BA logic is now handled by completely new code in the driver, with a bypass of the corresponding logic in net80211. We now let the firmware move the BA window forward and try to follow along, instead of maintaining our own (duplicated) state of the Rx BA session. net80211 is only involved in BA setup/teardown handshakes with the AP. In good conditions, I see virtually no packet loss. I've tried testing error recovery by moving far out and back to the AP. This seems to be OK. However, as with our net80211 Rx BA code we risk stuck connections if the Rx BA window doesn't resync properly after packet loss. The logic implemented here is from Intel, with very few changes (such as fixed timeout periods), so if the firmware and this new driver code work reliably on Linux, it should also work fine for us. But I cannot be sure that this code is free of bugs causing stuck connections. Like our net80211 Rx BA code, this code will have to prove itself over time...
