On 2021 Mar 30 (Tue) at 20:22:09 +0200 (+0200), Stefan Sperling wrote:
: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.
:
I can fly around pretty well in Minecraft while in 2 GHz, taking off is
easy to do.
However, when I go to a part of my apartment with dodgy wifi
connectivity, I notice that my signal strength goes down to 23%, and I
can't connect any more. I stay at HT-MCS15, even while it is flipping
around trying to connect. if I try to ping the gateway I get the
dreaded "ping: sendmsg: No buffer space available" error, until I
down/up the interface. That does occasionally happen without this diff,
so that is not a regression.
No noticable packet loss in my testing, even on 2GHz during the busiest
time of the day.
: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...
:
--
Misfortune, n.:
The kind of fortune that never misses.
-- Ambrose Bierce, "The Devil's Dictionary"
