Injection instability on 40MHz channels

[svpcom]

When I try to inject 4 mbit/s stream MCS1 using 40 MHz channel then card became periodically stall injection which leads to massive packet dropoff on RX side. The same injection on 20 MHz channel or using 8812au card @40MHz works fine. Receiving the same stream (generated by 8812au card) works without problem, so it seems this is TX-only issue

[snokvist]

I have the same issue, tried a multitude of settings with the same results.

[libc0607]

Do you have any clue on why that happened? I can't 100% reproduce that, but it does happen sometimes...

I tended to conclude that it was some interference (as in a wider band there's a higher chance), but that could be wrong and it's a bug somewhere...?

[svpcom]

@libc0607 This only happened when sufficient amount of traffic exists. I.e. if I'll transmit separate packets it will not happened. I have no idea how to debug it - only to compare some pieces of code with 8812au driver (it doesn't have such problem)

[svpcom]

test video pipeline to reproduce:

gst-launch-1.0 videotestsrc is-live=true ! 'video/x-raw,format=I420,width=1920,height=1080,framerate=30/1' ! clockoverlay halignment=right valignment=top text=src ! x264enc tune=zerolatency bitrate=4000 intra-refresh=true ! rtph264pay aggregate-mode=zero-latency mtu=1400 config-interval=1 ! udpsink host=127.0.0.1 port=5602 sync=false

test hw setup: x86 laptop with 8812eu (wlan1) and 8812au (wlan2)
wifibroadcast.cfg

[common]
wifi_channel = 149
wifi_txpower = {'wlan1': 100, 'wlan2': -100}

[base]
bandwidth = 40
mcs_index = 1
use_qdisc = True

wfb-ng config:

1. wfb-server --profiles drone --wlan wlan1
2. wfb-server --profiles gs --wlan wlan2

modprobe config

# blacklist stock module
blacklist 88XXau
blacklist 8812au
options cfg80211 ieee80211_regdom=RU
options 88XXau_wfb rtw_tx_pwr_idx_override=1
options 8812eu rtw_tx_pwr_by_rate=0 rtw_tx_pwr_lmt_enable=0

[libc0607]

Still can't reproduce. So don't know what's going on :(
Tried the above with 2 8812eu several times, with enough traffic...

I haven't touched anything about 40MHz yet, could that be some bug by Realtek?

[svpcom]

@libc0607 I'm unable to reproduce it exactly, but when I run python3 -m wfb_ng.latency_test 5602 5600 1500 2000 over wfb-ng standard video link channel with 40Mhz bw (mcs1, fec 8/12, bw 40) then if 8812au tx and 8812eu rx I get stable 13 mbit/s bitrate with latency < 5ms. If 8812eu tx and 8812au rx then latency can be very worse and bitrate with < 5ms latency will be from: 3 mbit/s to 12 mbit/s during several consequent runs. No such problem with dual 8812au cards or with 8812eu cards at 20MHz bw.

[svpcom]

@libc0607 how to reproduce:

1. connect 8812au as wlan1 and 8812eu as wlan2 to PC
2. Add to /etc/wifibroadcast.cfg

[common]
wifi_txpower = {'wlan1': -100, 'wlan2': 100}  # set min power to both cards
wifi_channel = 161

[base]
force_vht = False
bandwidth = 40
mcs_index = 1
use_qdisc = True

3. Run sudo wfb-server --profiles drone --wlans wlan2 # 8812eu will tx
4. Run sudo wfb-server --profiles gs --wlans wlan1 # 8812au will rx
5. Run sudo wfb-test-latency 5602 5600 1500 2000 # start test with initial pkt rate 2000 pkt/s with 1500 bytes packets

Also it is interesting that even with 20MHz channel   eu -> au produce max 6.8 mbit/s and au -> eu 7.4 mbit/s

[svpcom]

P.S. All bitrate are with 8/12 FEC overhead - raw bitrates will be 1.5x faster

[svpcom]

8812au card(s) in test above are alfa awus036ach connected to usb3 ports.
There were tests:

1. au -> au
2. au -> eu
3. eu -> au

[libc0607]

I've tested 40MHz on 8812au, 8812cu, 8812eu, and 8733bu respectively, only 8812au and 8733bu seem to be performing good...

Considering that these drivers are all just filling 40MHz to TXDESC (especially 8812cu/eu/8733bu, their drivers are really similar, just string replacements), and not touching anything else related to 40mhz, I'd like to say the difference is in firmware/hardware...

waterfall plot:
8812au, seems pretty good:

8733bu, good too:

8812eu, with occasionally stuck:

8812cu, barely usable:

(Why does realtek make tons of chip designs, but all of them have different bugs and none of them is perfect...

[svpcom]

@libc0607 Is it a test mode (when it internally transmit continuous signal) or you try to feed max possible packet rate?

[libc0607]

@libc0607 Is it a test mode (when it internally transmit continuous signal) or you try to feed max possible packet rate?

filled wfb_tx with random data to the maximum rate. haven't tested the internal mode yet

[libc0607]

Found the 8812cu MP toolkit, and tried 40MHz "Packet TX" mode
the spectrum seems solid, and the packet can be received & decoded

So the good news is at least jaguar3 hardware can work with 40MHz injection. Gonna find out what's happening

[ozy]

Interestingly something very similar happens for me on 20mhz. Not reproducable with 40mhz. Couple of test packets works with 20mhz and it stops after i send a couple of big packets. No relevant journal logs. No dmesg messages. Disabled all kind of services that may interfere but no luck.

[svpcom]

@ozy How do you power the card? Try to set minimum tx power -- will it help?

[ozy]

@svpcom good point. My power setup is 5v injected to usb hub from adjustable (shitty) PSU + 100uf capacitor. But it turns out these 1watt 8812eu modules pull enough current during tx to cause voltage drop to 4.5 volts (even @ 20db).

As you suggest looks like power issue, it's stable @ 5db 20mhz.
Thanks

[libc0607]

Update: Did some timing analysis on the call stack. There's nowhere stuck in the driver, the jitter occurs between usb_write_port() and the callback usb_write_port_complete().

[svpcom]

@libc0607
Does it mean hardware bug?
Does 40MHz stuck also triggered in normal (Client or AP) mode?

Update: Did some timing analysis on the call stack. There's nowhere stuck in the driver, the jitter occurs between usb_write_port() and the callback usb_write_port_complete().

[libc0607]

Does it mean hardware bug?

Still don't know. ( Most likely it's hardware/firmware bug, but the packet TX works well in MPTool (with Windows driver)...

So it could be 1. HW/FW bug, and MPTool uses some internal test mode, or 2. Linux driver doesn't config the hardware correctly
For 2, I've tried: 1. the EDCCA config seems not related -- tried different thresholds, 2. the different queue (VI/VO/BK/BE/MGNT...) setting not related

Does 40MHz stuck also triggered in normal (Client or AP) mode?

Haven't tried that

[JasonFreeLab]

找到了 8812cu MP 工具包，并尝试了 40MHz 的“数据包发送”模式，频谱看起来稳定，数据包可以接收和解码

所以好消息是至少 jaguar3 硬件可以在 40MHz 注入下工作。要找出发生了什么

@libc0607 Hello, can you provide me with the 8812cu MP tool kit? I have professional RF test equipment here and can help reproduce the problem.

[libc0607]

@libc0607 Hello, can you provide me with the 8812cu MP tool kit? I have professional RF test equipment here and can help reproduce the problem.

Hi, ... I got that tool from someone (who most likely signed NDA) and I'm not sure that he would allow me to redistribute that.
The 40MHz instability issue can be reproduced by wfb_tx with fulfilled traffic, please see svpcom's commands above