Problems with Realtek wireless adapters, 10.41.12.0006, AP3705i

[wsgc]

C35 Controller running 10.41.12.0006
AP AP3705i
Client: Lenovo A485, Windows 10Pro - Realtek 8822BE chipset

We have issues with some clients that have Realtek chipsets when they are on 5ghz and associated with the 3705 AP. They experience extremely high latency: ping times to the nearest switch on the network over 2 seconds. Also some clients are not always able to connect after being off the network for a while.

The clients when at a different site with newer APs(38xx,39xx)) do not have this problem. We'd like to get this solved without having to buy new APs because the 3705 is still supported.

Example:

Suspend laptop. Resume next day.

Windows unable to get a working connecton.

Proto: 5.0n|L,W
RSS: -56
Avg.Rate(Mbps)/Sent/Rec'd: 300/100
Ping time to switch: 1000-2500ms

Disassociate laptop from controller. Laptop does not connect again(Windows 10 doesn't bother trying to reconnect).
Force reconnection from client. Works.

Proto: 5.0n|L,W
RSS: -55
Avg.Rate(Mbps)/Sent/Rec'd: 254/80
Ping time to switch: 500-2800ms

Disassociate. Force reconnection.

Proto: 5.0n|L,W
RSS: -55
Avg.Rate(Mbps)/Sent/Rec'd: 254/80
Ping time to switch: 100-1000ms

Forcing laptop adapter to use 802.11b/g/n on 2.4ghz fixes problem.

802.11b/g/n(2.4)
Proto: 2.4n
RSS: -57
Avg.Rate(Mbps)/Sent/Rec'd: 104/172
Ping time to switch: <5ms

[dpanev]

I gues your laptop cant “see” the ssid sent from the AP650 because its ax and the 1130 sents on ac

[systemscsn]

Thank you StephenH and Tomasz for explaining that.  WOW, just wow.  I had NO idea that is what they did, literally fall asleep as fast as grandpa after a Thanksgiving turkey dinner!

Its explanations like both of yours, that make me realize how little I know about wifi. I really thought i knew a lot, and maybe i do.  But its this kind of granular knowledge that shows me that I dont have that much knowledge.

I suppose that if your single job is wifi, then that's all you concentrate on, study and test on and truly become an expert on.  Unfortunately for my position, its a means to an end and just one of many services we offer our students, staff and faculty and just one small part of the many other things I have to manage.  I think the saying is, jack of all trades, master of none.

Back to the network cards, and Windows OS.  Am I imagining that when Windows does one of their large update (I believe its a new OS - like the latest one 20hSomething from 1909) its putting their Microsoft “default” driver back onto the computer?  I have a laptop that I know had the old  MS driver removed (the proper way - uninstalling it) and the actual manufacturer’s driver installed.  But its back to its old behavior, and connecting to an Outdoor AP (1130) that’s over 100 feet away, versus an AP (650AH) that's in the same room as the laptop!

Any ideas about that?

Thanks again so much for all your help up to this point, i greatly appreciate it.

Best,

Jason.

[Tomasz]

How is that even possible? to fall asleep in between pings?  if its a reply, like it is in this case (when it finally connects, even 2 seconds shouldn't be long enough for power management to kick the computer into sleep… 

Thanks,

J.

Hi,

That is in fact possible. I had such problem once, someone had DTIM set to 5 and beacon interval increased to something like 300. Stations were allowed to put their WLAN to sleep for 1.5 s. This was devastating for their throughput tests and also for connection stability. A stationary device was roaming every minute between two APs back and forth (similar RSSI from both) totally loosing any throughput on iperf for few seconds before roaming. Fixing beacon interval back to 100 TU (100 ms in IdentiFi notion) helped. That’s why I asked as increased delays might occur with couple of issues (design/environment) but that one came to my mind first.

Hope that helps,

Tomasz

[StephanH]

Hello J,

the easiest way to see what happen here is to do a trace in the air. With such a trace you will see powersafe, too.

On XIQ you can create a trace in “Manage->Tools->Packet capture”

[StephanH]

Hello J,

Two seconds is an eternity in WLAN.

A WLAN client can go to sleep immediately after it has sent a packet completely and it then wakes up (not true for AX, 802.11ax is using TWT) whenever a TIM (traffic indicator map) is sent. This is defined by the DTIM interval. I.e. if the beacon period is 100ms and DTIM is 5, then the client must wake up every 500ms to read the beacon with the TIM and check whether there is data for it. You see if it has to wait two seconds for something then it could fall asleep up to 4 times to save energy.