RE: Performance of Reassociation

[Ping-Ke Shih <pkshih@realtek.com>]

Jesuiter, Henry <henry.jesuiter@softing.com> wrote:
> 
> we are using the rtw88 driver (with kernel 5.4) together with a RTL8822ce chip (Firmware 9.9.15, WOW 9.9.4,
> H2C Version 15) on a PCI-Express card. We stumbled about long roaming durations and investigated a little
> into this issue, by using different hardware:
>     * Freescale i.MX6/ARMv7
>     * Intel Core i5-7300)
> 
> and different distributions:
>    * Yocto Hardknott/3.3.6, Kernel 5.4
>    * Buildroot, Kernel 6.6
>    * Ubuntu 20.04, Kernel 5.15
>    * Ubuntu 24.04, Kernel 6.8
> 
> and found roaming times from 450ms (Ubuntu 24.04, Intel) up to 900ms (Yocto 3.3.6, FreeScale).

Does it mean 450ms on kernel 5.15, but 900ms on kernel 5.4 for RTL8822ce?

> 
> Since we are used to much shorter roaming times (about 200ms even on the Freescale), 

What is the WiFi card you are used to measure this roaming time?


> 2. Start authentication to the new AP
>     [  561.557691] wlan0: authenticate with <new_ssid>
> 2.1 Reinitialize the hardware
>     [  561.577099] rtw_8822ce 0000:01:00.0:  rtw_power_on()
>     [  561.577109] rtw_8822ce 0000:01:00.0:  rtw_hci_setup()
>     [  561.577128] rtw_8822ce 0000:01:00.0:  rtw_mac_power_on()
>     [  561.577262] rtw_8822ce 0000:01:00.0:  rtw_mac_power_switch()
>     [  561.580561] rtw_8822ce 0000:01:00.0:  rtw_wait_firmware_completion()
>     [  561.584826] rtw_8822ce 0000:01:00.0:  rtw_download_firmware()
> => about 40ms here
>     [  561.614635] rtw_8822ce 0000:01:00.0: rtw_hci_setup()
>     [  561.614657] rtw_8822ce 0000:01:00.0: rtw_mac_init()
> => about 250ms here
>     [  561.876080] rtw_8822ce 0000:01:00.0: rtw_hci_start()
>     ...

I measure rtw_leave_ips() which is to power on wifi card, and the cost is
about 200ms in my x86 NB.

> 2.2 PHY calibration
>     [  561.877140] rtw_8822ce 0000:01:00.0: [RFK] WiFi / BT RFK handshake start!!
>     ...
>     [  561.896456] rtw_8822ce 0000:01:00.0: [RFK] WiFi / BT RFK handshake finish!!
>     [  561.936393] rtw_8822ce 0000:01:00.0: [DPK] s0 dpk start
>     [  562.056272] rtw_8822ce 0000:01:00.0: [DPK] s0 dpk finish
>     [  562.056280] rtw_8822ce 0000:01:00.0: [DPK] s1 dpk start
>     [  562.176275] rtw_8822ce 0000:01:00.0: [DPK] s1 dpk finish
> => about additional 300ms until here (that's the phy calibration stuff)

I measure rtw_chip_prepare_tx() which is to do phy calibration. The cost is
about 190ms on 2GHz and 5GHz channels. 

> 
> So, we are wondering if this long duration times for reassociation are hardware-related (maybe even someone
> uses the same chip and does not experience these delays)?
> 
> On the software side, is there some optimization potential known in the software/driver that is just not
> realized yet? We would be happy to realize/implement those potentials. To be more specific: We are looking
> for a way that the driver does not need to reinitialize/restart the hardware while roaming in order to reduce
> that part of the roaming delay specifically (and maybe skip/shorten the phy_calibration part). Any ideas
> are welcome. We are also happy to provide any additional logs that might be needed (please specify) and
> to answer any additional question you might have.

The costs I posted are hardware-related. Ignore IEEE80211_CONF_IDLE to avoid calling
rtw_enter_ips()/rtw_leave_ips(), saving 200ms to power on hardware. 

For PHY calibration, I think this is strictly necessary to get good performance.
One way may be deferred the calibration after getting connected, but 4 way and 
DHCP (right after getting connected) may not work well result from bad RF signal
quality.