search

espressif / esp-hosted

Hosted Solution (Linux/MCU) with ESP32 (Wi-Fi + BT + BLE)
Other
701 stars 166 forks source link

FG : SoftAp mode : WiFi ping delay is high and unstable(esp32c3, host-fg) #457

Open ShengjieCh opened 2 months ago

ShengjieCh commented 2 months ago

After the mobile phone is connected to the ESP32's WiFi, I use the ESP32 to ping the mobile phone. In the case of no interference and close distance (in a shielded box), I found that the ping delay is very high and unstable. Is there any way to reduce the delay and fluctuation? image image

mantriyogesh commented 2 months ago

Can you disable modem power save for wifi and try again?

ShengjieCh commented 2 months ago

Where can I disable modem power save for wifi? I can't find this item in idf.py menuconfig.

mantriyogesh commented 2 months ago

For now you can disable directly in the slave using https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_wifi.html#_CPPv415esp_wifi_set_ps14wifi_ps_type_t

Ideally we have support changing power save for wifi from host using https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/docs/common/ctrl_apis.md#19-ctrl_cmd_t--wifi_set_power_save_modectrl_cmd_t-req . but WIFI_PS_NONE due to crash when BT+Wi-Fi co-ex case with no power save.

If you still wish to do it from host, with simple changes, it is still do-able.

  1. Comment: https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/host/control_lib/src/ctrl_core.c#L1401-L1406

  2. Add case 

                case 0 /*WIFI_PS_NONE*/ : 
                printf("No_PS\n\r");
                break;

    at https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/host/stm32/app/control/control_utils.c#L383

  3. Add 

    int test_set_wifi_power_save_mode_none(void)
{
return test_set_wifi_power_save_mode(0);
}

  4. Change slave side: https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/esp/esp_driver/network_adapter/main/slave_control.c#L1409-L1410 to

    if ((req->req_set_power_save_mode->mode == WIFI_PS_NONE) ||
    (req->req_set_power_save_mode->mode == WIFI_PS_MIN_MODEM) ||
    (req->req_set_power_save_mode->mode == WIFI_PS_MAX_MODEM)) {

Anyway, this fix we would add in next batch of control commands fixes.

ShengjieCh commented 2 months ago

Hi, yogesh: From the packet capture, the wifi did not enter sleep mode. I captured an packet from the wifi port during ping. esp32 wifi also has fluctuations in ping delay at close range. The link is a log of wifi air port packet capture and ping. The expected delay should be around 10ms, but there is a ping delay jitter of more than 100ms. I hope you can help analyze this problem and whether there are any optimization methods. The ping cycle is once every 2 seconds. log and capture: ping.zip image

mantriyogesh commented 2 months ago

What is the host used and what is the transport?

mantriyogesh commented 2 months ago

Also is there any activity for bluetooth?

ShengjieCh commented 2 months ago

The host uses RV1106, Linux system, spi. Bluetooth has no data transmission or reception.

mantriyogesh commented 2 months ago

We will try to reproduce this at our end. Can you change https://github.com/espressif/esp-hosted/blob/7d807b4a00b1be32f77b7a98702ecfd05f4628a5/esp_hosted_fg/host/linux/host_driver/esp32/spi/esp_spi.c#L342

To 

/*  rx_pending = gpio_get_value(spi_context.dataready_gpio);*/
rx_pending = 1;

and reload host driver?

ShengjieCh commented 2 months ago

I tried this method, but it did not improve the problem of ping packet delay fluctuations. image

mantriyogesh commented 2 months ago

I will try to reproduce this issue at my side.

In prior method, the transaction would take place without idling spi bus. Even when the bus not getting idle, the ping getting jitter, intermittently, which is very doubting. If you have logic analyser, it would be very useful, to rule out the case.

ShengjieCh commented 2 months ago

I will try to use a logic analyzer to analyze the problem today. I also noticed that there are some block ack establishment failures in the air interface packet capture. Do you know what the reason is? image

mantriyogesh commented 2 months ago

the test you are performing should ideally be done in the shield box, where the network is isolated. the interference and noise play a great role for Wi-Fi.

In general, assess that you are using less crowded Wi-Fi channel and change the Bandwidth to HT40. Avoid using bluetooth , microwave and other Wi-Fi devices in same channel nearby. Can also set auto channel option in router, if is not yet set.

On wireless interface drops can happen for a lot of reasons. the ping packets by default are send very less frequently. but the still face contention and other interference issues. I think it would be good comparison to compare with esp-idf native example, https://github.com/espressif/esp-idf/tree/master/examples/protocols/icmp_echo could be run on exact same hardware (standalone example, instead of esp-hosted slave firmware), in the same rf environment.

if you happen to have shield box, it would be perfect.

ShengjieCh commented 2 months ago

Will the failure of establishing the block ack mentioned above affect the ping latency?

mantriyogesh commented 2 months ago

it is directly related. with block acks, you save a lot time. without or frequent failures in block acks will lead to increased overhead due to individual acknowledgments, higher retransmission rates, reduced efficiency in frame aggregation, and overall higher network congestion.

While chekcing the wireshark, I found that either side is not espressif mac address. Screenshot 2024-08-15 at 10 55 12 AM

Should I assume, you are using your own MAC address? or are you using wrong interface?

ShengjieCh commented 2 months ago

Yes, I used a custom wifi mac address. would that cause this problem?

ShengjieCh commented 2 months ago

the test you are performing should ideally be done in the shield box, where the network is isolated. the interference and noise play a great role for Wi-Fi.

In general, assess that you are using less crowded Wi-Fi channel and change the Bandwidth to HT40. Avoid using bluetooth , microwave and other Wi-Fi devices in same channel nearby. Can also set auto channel option in router, if is not yet set.

On wireless interface drops can happen for a lot of reasons. the ping packets by default are send very less frequently. but the still face contention and other interference issues. I think it would be good comparison to compare with esp-idf native example, https://github.com/espressif/esp-idf/tree/master/examples/protocols/icmp_echo could be run on exact same hardware (standalone example, instead of esp-hosted slave firmware), in the same rf environment.

if you happen to have shield box, it would be perfect. I used this example to test ping https://pan-sec.djicorp.com/s/4ciJAw9G96LHX8a

mantriyogesh commented 2 months ago

Which is just perfect I would say.

Please wait, I will also test this at my place, on Raspberry Pi and confirm if I can replicate this issue.

ShengjieCh commented 2 months ago

It is found that block ack is repeatedly requested and deleted image

mantriyogesh commented 2 months ago

Can you please send TK, to decode the capture?

ShengjieCh commented 2 months ago

SSID:OnePlus11 passwd:88888888

ShengjieCh commented 2 months ago

Could you replicate this issue on your side? Raspberry Pi + SPI +ESP32C3(host-fg)

ShengjieCh commented 2 months ago

Can you verify the AT firmware using the same environment at the same time? Raspberry Pi + SPI +ESP32C3(AT)

ShengjieCh commented 2 months ago

Hi, yogesh, Is there any progress?

mantriyogesh commented 2 months ago

Hello @ShengjieCh ,

I tried the ping scenario yesterday as a trial, the ping was RTT was ranging in between 10ms to 39ms for me. I will capture the sniffer and attach it here, by tomorrow.

Host used: Raspberry Pi Environment: CISCO C9120AXI-S router


    graph LR
    B[Router]
    C[ESP] <-->|SPI| A[Host]
    C -. Wi-Fi .-> B
     A -. Wi-Fi .-> B

    style B fill:#f9f,stroke:#333,stroke-width:2px;
    style C fill:#bbf,stroke:#333,stroke-width:2px;
    style A fill:#bbf,stroke:#333,stroke-width:2px;

This was over the air setup, not shield box. but with default settings. I am checking if I can optimize anything, to get further lower RTT.

Please note, if you use the wires, the interrupt latency would be high, SPI communication also would be slower. If I get to reproduce on other wifi router, I will further try along with sniffer capture.

ShengjieCh commented 2 months ago

Can you use a phone to connect to the ESP32 softAP and ping it (keep the test method the same). Please help confirm whether the same block ack establishment failure occurs in the air interface packet capture.

mantriyogesh commented 2 months ago

wlan.addr == 40:4c:ca:4a:a8:50

Screenshot 2024-08-20 at 9 28 26 PM

I see block acks are just fine. Sniffer attached with the Phone as hotspot. Phone model: Xiaomi 5G Hypercharge

The ping req - resp is just fine.

Mantri’s MacBook Pro_ch1_2024-08-20_21.26.05.986.pcap.zip

kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=50.8 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=45.7 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=45.2 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=64.9 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=43.10 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=43.8 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=42.1 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=42.9 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=41.6 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=113 time=40.6 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=113 time=40.8 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=113 time=39.7 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=113 time=46.10 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=113 time=38.7 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=113 time=57.1 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=113 time=36.9 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=113 time=49.6 ms
^C
--- 8.8.8.8 ping statistics ---
22 packets transmitted, 17 received, 22.7273% packet loss, time 265ms
rtt min/avg/max/mdev = 36.888/45.370/64.920/6.852 ms
mantriyogesh commented 2 months ago

ESP logs for above:

I (2556978) slave_ctrl: Disconnected from previously connected AP
I (2556985) slave_ctrl: station mode set
I (2556989) slave_ctrl: Get station mac address
I (2556994) slave_ctrl: mac [40:4c:ca:4a:a8:50]
W (2557000) wifi:Password length matches WPA2 standards, authmode threshold changes from OPEN to WPA2
I (2557010) slave_ctrl: Station disconnected, reason[8]
I (2559712) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1, snd_ch_cfg:0x0
I (2559712) wifi:(connect)dot11_authmode:0x3, pairwise_cipher:0x3, group_cipher:0x3
I (2559716) wifi:state: init -> auth (0xb0)
I (2559727) wifi:state: auth -> assoc (0x0)
I (2559739) wifi:(assoc)RESP, Extended Capabilities length:10, operating_mode_notification:0
I (2559740) wifi:(assoc)RESP, Extended Capabilities, MBSSID:0, TWT Responder:0, OBSS Narrow Bandwidth RU In OFDMA Tolerance:0
I (2559748) wifi:Extended Capabilities length:10, operating_mode_notification:0
I (2559755) wifi:state: assoc -> run (0x10)
I (2559759) wifi:(trc)phytype:CBW20-SGI, snr:57, maxRate:144, highestRateIdx:0
W (2559766) wifi:(trc)band:2G, phymode:3, highestRateIdx:0, lowestRateIdx:11, dataSchedTableSize:14
I (2559774) wifi:(trc)band:2G, rate(S-MCS7, rateIdx:0), ampdu(rate:S-MCS7, schedIdx(0, stop:8)), snr:57, ampduState:wait operational
I (2559786) wifi:ifidx:0, rssi:-26, nf:-83, phytype(0x3, CBW20-SGI), phymode(0x3, 11bgn), max_rate:144, he:0, vht:0, ht:1
I (2559797) wifi:(ht)max.RxAMPDULenExponent:3(65535 bytes), MMSS:0(no restriction)
I (2559814) wifi:connected with SaveEarth, aid = 1, channel 1, BW20, bssid = ae:06:fb:8c:1a:b8
I (2559814) wifi:cipher(pairwise:0x3, group:0x3), pmf:0, security:WPA2-PSK, phy:11bgn, rssi:-26
I (2559821) wifi:pm start, type: 1, twt_start:0

I (2559825) wifi:pm start, type:1, aid:0x1, trans-BSSID:ae:06:fb:8c:1a:b8, BSSID[5]:0xb8, mbssid(max-indicator:0, index:0), he:0
I (2559836) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (2559845) wifi:set rx beacon pti, rx_bcn_pti: 10, bcn_timeout: 25000, mt_pti: 10, mt_time: 10000
I (2559853) wifi:[ADDBA]TX addba request, tid:0, dialogtoken:10, bufsize:64, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0)
I (2559865) wifi:[ADDBA]TX addba request, tid:7, dialogtoken:11, bufsize:64, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x20)
I (2559876) wifi:[ADDBA]TX addba request, tid:5, dialogtoken:12, bufsize:64, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0)
I (2559887) slave_ctrl: connected to ap SSID:'SaveEarth', password:'PlantMoreTrees123'
I (2559895) wifi:[ADDBA]RX addba response, status:0, tid:0/tb:1(0xa1), bufsize:64, batimeout:0, txa_wnd:64
I (2559905) wifi:[ADDBA]RX addba response, status:0, tid:7/tb:1(0xa1), bufsize:64, batimeout:0, txa_wnd:64
I (2559914) wifi:dp: 2, bi: 102400, li: 4, scale listen interval from 307200 us to 409600 us
I (2559922) wifi:AP's beacon interval = 102400 us, DTIM period = 2
I (2559929) wifi:[ADDBA]RX addba response, status:0, tid:5/tb:1(0xa1), bufsize:64, batimeout:0, txa_wnd:64
I (2559939) slave_ctrl: Wifi Connected
I (2567328) slave_ctrl: Stop Heatbeat
I (2567328) slave_ctrl: Stopping HB timer
W (2581127) wifi:<ba-add>idx:0, ifx:0, tid:3, TAHI:0x100b81a, TALO:0x8cfb06ae, (ssn:4, win:64, cur_ssn:4), CONF:0xc0003005
W (2632252) wifi:<ba-add>idx:1, ifx:0, tid:0, TAHI:0x100b81a, TALO:0x8cfb06ae, (ssn:4, win:64, cur_ssn:4), CONF:0xc0000005
mantriyogesh commented 2 months ago

Test with standard Router

Ping tested with same environment but with standard AP or Xiaomi router.

Also please note, These all test do not have any Power saving disabled (default config).

Sniffer: Mantri’s MacBook Pro_ch11_2024-08-20_21.42.01.211.pcap.zip

SSID: Xiaomi_8A9A Pwd: PlatMoreTrees123

Ping sample log extracted from below logs:

64 bytes from 8.8.8.8: icmp_seq=4 ttl=108 time=10.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=108 time=9.90 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=108 time=12.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=108 time=10.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=108 time=9.74 ms

Once we disable the Power save, I expect even better RTT than this for pin.

Summary

With all the tests I can clearly see that there is no issue in ESP-Hosted. I request you to verify in less noisy and different AP.

Detailed Logs

Environment ![Screenshot 2024-08-20 at 9 20 21 PM](https://github.com/user-attachments/assets/63ee4405-16f9-4573-9898-570e09b90308) --- ![Screenshot 2024-08-20 at 9 20 07 PM](https://github.com/user-attachments/assets/f961b8d1-7e00-40f8-b0ee-3429c6b75271)
ESP log: ESP Log ``` I (3509499) wifi:state: run -> init (0x0) I (3509500) wifi:pm stop, total sleep time: 896542534 us / 949663440 us I (3509500) wifi:idx:1, tid:0 I (3509502) wifi:idx:0, tid:3 I (3509505) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1, snd_ch_cfg:0x0 I (3509513) slave_ctrl: Disconnected from previously connected AP I (3509520) slave_ctrl: station mode set I (3509524) slave_ctrl: Get station mac address I (3509529) slave_ctrl: mac [40:4c:ca:4a:a8:50] W (3509535) wifi:Password length matches WPA2 standards, authmode threshold changes from OPEN to WPA2 I (3509545) slave_ctrl: Station disconnected, reason[8] I (3509553) wifi:(he)max.RxAMPDULenExponentExtension:3, max.RxAMPDUpre-EOFpaddingBytes:8388607(0x7fffff) I (3509559) wifi:(mac)omc_ul_mu_data_disable_rx:1 I (3509563) wifi:(phy)ppe_thresholds_present:1, nominal_packet_padding:0 I (3509569) wifi:(phy)dcm tx(constellation:0, nss:0), dcm rx(constellation:1, nss:0) I (3509577) wifi:(phy)rx_mcs_map:0xfffa, tx_mcs_map:0xfffa, stbc_tx:0, bfmer(su:1, mu:1), ldpc:1, max_rate:172 I (3509587) wifi:(phy)nsts:2, ru_index_bitmap:0x3(242:1, 484:1, 996:0, 2*996:0) I (3509594) wifi:(phy)threshold_bits:24, nsts_num:2, ru_num:2, he_cap->len:26, ppe_threshold_len:4(6,11,4) I (3509603) wifi:(ppe)RU242, NSTS0, PPE16:0, PPE8:7, nominal_packet_padding:2 I (3509610) wifi:(opr)len:7, TWT Required:0, VHT Opr Info Present:0, 6GHz Opr Info Present:0, Co-Hosted BSS:0(max_indicator:0), Basic MCS and NSS:0xfffc I (3509623) wifi:(opr)len:7, Default PE Duration:4, TXOP RTS Threshold:1023(0 us), ER-SU-Disable:0 I (3509632) wifi:(opr)len:7, BSS Color:5, disabled:0, Partial BSS Color:0 I (3509638) wifi:(spr)len:2, ctrl:0x3, PSR Disallowed:1, Non-SRG OBSS PD SR Disallowed:1 I (3509646) wifi:(spr)len:2, ctrl:0x3, Non-SRG Offset Present:0, SRG Info Present:0 I (3512247) wifi:new:<11,0>, old:<1,0>, ap:<255,255>, sta:<11,0>, prof:1, snd_ch_cfg:0x0 I (3512248) wifi:(connect)dot11_authmode:0x3, pairwise_cipher:0x3, group_cipher:0x3 I (3512252) wifi:state: init -> auth (0xb0) I (3512260) wifi:state: auth -> assoc (0x0) I (3512272) wifi:(assoc)RESP, Extended Capabilities length:11, operating_mode_notification:0 I (3512272) wifi:(assoc)RESP, Extended Capabilities, MBSSID:0, TWT Responder:0, OBSS Narrow Bandwidth RU In OFDMA Tolerance:0 I (3512280) wifi:Extended Capabilities length:11, operating_mode_notification:1 I (3512288) wifi:(he)max.RxAMPDULenExponentExtension:3, max.RxAMPDUpre-EOFpaddingBytes:8388607(0x7fffff) I (3512297) wifi:(mac)omc_ul_mu_data_disable_rx:1 I (3512301) wifi:(phy)ppe_thresholds_present:1, nominal_packet_padding:0 I (3512307) wifi:(phy)dcm tx(constellation:0, nss:0), dcm rx(constellation:1, nss:0) I (3512315) wifi:(phy)rx_mcs_map:0xfffa, tx_mcs_map:0xfffa, stbc_tx:0, bfmer(su:1, mu:1), ldpc:1, max_rate:172 I (3512325) wifi:(phy)nsts:2, ru_index_bitmap:0x3(242:1, 484:1, 996:0, 2*996:0) I (3512332) wifi:(phy)threshold_bits:24, nsts_num:2, ru_num:2, he_cap->len:26, ppe_threshold_len:4(6,11,4) I (3512341) wifi:(ppe)RU242, NSTS0, PPE16:0, PPE8:7, nominal_packet_padding:2 I (3512348) wifi:(opr)len:7, TWT Required:0, VHT Opr Info Present:0, 6GHz Opr Info Present:0, Co-Hosted BSS:0(max_indicator:0), Basic MCS and NSS:0xfffc I (3512361) wifi:(opr)len:7, Default PE Duration:4, TXOP RTS Threshold:1023(0 us), ER-SU-Disable:0 I (3512370) wifi:(opr)len:7, BSS Color:5, disabled:0, Partial BSS Color:0 I (3512376) wifi:BSS max idle period:291(1000TU), protected keep alive:FALSE I (3512383) wifi:state: assoc -> run (0x10) I (3512387) wifi:(he)ppe_thresholds_present:1, nominal_packet_padding(rx:0, cfg:2) I (3512394) wifi:(trc)phytype:CBW20-SGI, snr:64, maxRate:172, highestRateIdx:0 W (3512401) wifi:(trc)band:2G, phymode:3, highestRateIdx:0, lowestRateIdx:11, dataSchedTableSize:14 I (3512410) wifi:(trc)band:2G, rate(S-MCS7, rateIdx:0), ampdu(rate:S-MCS7, schedIdx(0, stop:8)), snr:64, ampduState:wait operational I (3512422) wifi:ifidx:0, rssi:-19, nf:-83, phytype(0x3, CBW20-SGI), phymode(0x7, 11ax), max_rate:172, he:1, vht:0, ht:1 I (3512432) wifi:(ht)max.RxAMPDULenExponent:3(65535 bytes), MMSS:0(no restriction) I (3512451) wifi:(extcap)mbssid:0, enhanced_mbssid_advertise:0, complete_nontxbssid_profiles:0, twt_responder: 0 I (3512451) wifi:connected with Xiaomi_8A9A, aid = 1, channel 11, BW20, bssid = 50:88:11:b2:2a:6a I (3512459) wifi:cipher(pairwise:0x3, group:0x3), pmf:0, security:WPA2-PSK, phy:11ax, rssi:-19 I (3512467) wifi:pm start, type: 1, twt_start:0 I (3512471) wifi:pm start, type:1, aid:0x1, trans-BSSID:50:88:11:b2:2a:6a, BSSID[5]:0x6a, mbssid(max-indicator:0, index:0), he:1 I (3512483) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us I (3512491) wifi:set rx beacon pti, rx_bcn_pti: 10, bcn_timeout: 25000, mt_pti: 10, mt_time: 10000 I (3512500) wifi:[ADDBA]TX addba request, tid:0, dialogtoken:13, bufsize:32, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0) I (3512511) wifi:[ADDBA]TX addba request, tid:7, dialogtoken:14, bufsize:32, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x20) I (3512522) wifi:[ADDBA]TX addba request, tid:5, dialogtoken:15, bufsize:32, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0) I (3512534) wifi:AP's beacon interval = 102400 us, DTIM period = 1 I (3512540) wifi:[ADDBA]RX addba response, status:0, tid:0/tb:1(0xa1), bufsize:32, batimeout:0, txa_wnd:32 I (3512549) wifi:[ADDBA]RX addba response, status:0, tid:7/tb:1(0xa1), bufsize:32, batimeout:0, txa_wnd:32 I (3512558) wifi:[ADDBA]RX addba response, status:0, tid:5/tb:1(0xa1), bufsize:32, batimeout:0, txa_wnd:32 I (3512567) slave_ctrl: connected to ap SSID:'Xiaomi_8A9A', password:'PlantMoreTrees123' I (3512577) slave_ctrl: Wifi Connected W (3513737) wifi:idx:0, ifx:0, tid:0, TAHI:0x1006a2a, TALO:0xb2118850, (ssn:0, win:64, cur_ssn:0), CONF:0xc0000005 I (3526701) slave_ctrl: Stop Heatbeat I (3526702) slave_ctrl: Stopping HB timer W (3539368) wifi:idx:1, ifx:0, tid:6, TAHI:0x1006a2a, TALO:0xb2118850, (ssn:2, win:64, cur_ssn:2), CONF:0xc0006005 ```
Ping log ``` kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ sudo ./test.out sta_connect Enable heartbeat with duration 20 Heartbeat operation successful ------ ESP-Hosted FW [FG-0.0.6.0.0] ------ Connect to AP[Xiaomi_8A9A] Requested operation complete Sleeping for some time just to showcase heartbeat ethsta0 interface down MAC address 40:4c:ca:4a:a8:50 set to ethsta0 interface ethsta0 interface up 2024-08-20 21:42:10 > App EVENT: STA-Disconnected reason[8] ssid[SaveEarth] bssid[ae:06:fb:8c:1a:b8] rssi[-33] 2024-08-20 21:42:10 > App EVENT: STA-Connected ssid[Xiaomi_8A9A] bssid[50:88:11:b2:2a:6a] channel[11] auth[3] aid[1] ^C Clean-up and exit Disable Heartbeat Heartbeat operation successful kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ sudo killall dhclient kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ sudo dhclient -v ethsta0 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/ethsta0/40:4c:ca:4a:a8:50 Sending on LPF/ethsta0/40:4c:ca:4a:a8:50 Sending on Socket/fallback DHCPREQUEST for 192.168.118.152 on ethsta0 to 255.255.255.255 port 67 DHCPNAK from 192.168.31.1 Too few arguments. DHCPDISCOVER on ethsta0 to 255.255.255.255 port 67 interval 4 DHCPOFFER of 192.168.31.181 from 192.168.31.1 DHCPREQUEST for 192.168.31.181 on ethsta0 to 255.255.255.255 port 67 DHCPACK of 192.168.31.181 from 192.168.31.1 Too few arguments. bound to 192.168.31.181 -- renewal in 18322 seconds. kysoh@raspberrypi:~/h2/esp_hosted_fg/host/linux/host_control/c_support $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=108 time=24.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=108 time=10.2 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=108 time=10.9 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=108 time=10.0 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=108 time=9.90 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=108 time=12.7 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=108 time=10.2 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=108 time=9.74 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=108 time=10.5 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=108 time=15.2 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=108 time=17.3 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=108 time=9.98 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=108 time=11.2 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=108 time=10.2 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=108 time=11.2 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=108 time=9.82 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=108 time=9.82 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=108 time=12.10 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=108 time=9.88 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=108 time=20.8 ms 64 bytes from 8.8.8.8: icmp_seq=21 ttl=108 time=9.83 ms 64 bytes from 8.8.8.8: icmp_seq=22 ttl=108 time=8.78 ms 64 bytes from 8.8.8.8: icmp_seq=23 ttl=108 time=10.5 ms 64 bytes from 8.8.8.8: icmp_seq=24 ttl=108 time=22.2 ms 64 bytes from 8.8.8.8: icmp_seq=25 ttl=108 time=9.94 ms 64 bytes from 8.8.8.8: icmp_seq=26 ttl=108 time=9.90 ms 64 bytes from 8.8.8.8: icmp_seq=27 ttl=108 time=9.97 ms 64 bytes from 8.8.8.8: icmp_seq=28 ttl=108 time=11.5 ms 64 bytes from 8.8.8.8: icmp_seq=29 ttl=108 time=14.5 ms 64 bytes from 8.8.8.8: icmp_seq=30 ttl=108 time=8.81 ms 64 bytes from 8.8.8.8: icmp_seq=31 ttl=108 time=9.79 ms 64 bytes from 8.8.8.8: icmp_seq=32 ttl=108 time=9.98 ms 64 bytes from 8.8.8.8: icmp_seq=33 ttl=108 time=11.6 ms 64 bytes from 8.8.8.8: icmp_seq=34 ttl=108 time=9.89 ms 64 bytes from 8.8.8.8: icmp_seq=35 ttl=108 time=9.70 ms 64 bytes from 8.8.8.8: icmp_seq=36 ttl=108 time=9.94 ms 64 bytes from 8.8.8.8: icmp_seq=37 ttl=108 time=13.9 ms 64 bytes from 8.8.8.8: icmp_seq=38 ttl=108 time=13.4 ms 64 bytes from 8.8.8.8: icmp_seq=39 ttl=108 time=11.5 ms 64 bytes from 8.8.8.8: icmp_seq=40 ttl=108 time=12.3 ms 64 bytes from 8.8.8.8: icmp_seq=41 ttl=108 time=10.0 ms 64 bytes from 8.8.8.8: icmp_seq=42 ttl=108 time=9.98 ms 64 bytes from 8.8.8.8: icmp_seq=43 ttl=108 time=10.1 ms 64 bytes from 8.8.8.8: icmp_seq=44 ttl=108 time=11.8 ms ^C --- 8.8.8.8 ping statistics --- 44 packets transmitted, 44 received, 0% packet loss, time 108ms rtt min/avg/max/mdev = 8.782/11.751/24.692/3.417 ms ``` ---
ShengjieCh commented 2 months ago

Can you use a phone to connect to the ESP32 softAP and ping it (keep the test method the same). Please help confirm whether the same block ack establishment failure occurs in the air interface packet capture.

I looked at the sniffer, and block acks were indeed established successfully. Can you let esp32 act as softAP and test it again to keep our testing method consistent (which is also the scenario we use).

mantriyogesh commented 2 months ago

ssid: newonw password: 12345678888

64 bytes from 192.168.4.9: icmp_seq=153 ttl=64 time=17.2 ms
64 bytes from 192.168.4.9: icmp_seq=154 ttl=64 time=116 ms
64 bytes from 192.168.4.9: icmp_seq=155 ttl=64 time=7.57 ms
64 bytes from 192.168.4.9: icmp_seq=156 ttl=64 time=93.10 ms
64 bytes from 192.168.4.9: icmp_seq=157 ttl=64 time=87.9 ms
64 bytes from 192.168.4.9: icmp_seq=158 ttl=64 time=7.79 ms
64 bytes from 192.168.4.9: icmp_seq=159 ttl=64 time=5.77 ms
64 bytes from 192.168.4.9: icmp_seq=160 ttl=64 time=24.6 ms
64 bytes from 192.168.4.9: icmp_seq=161 ttl=64 time=12.2 ms
64 bytes from 192.168.4.9: icmp_seq=162 ttl=64 time=190 ms
64 bytes from 192.168.4.9: icmp_seq=163 ttl=64 time=6.81 ms
64 bytes from 192.168.4.9: icmp_seq=164 ttl=64 time=8.18 ms
64 bytes from 192.168.4.9: icmp_seq=165 ttl=64 time=105 ms
64 bytes from 192.168.4.9: icmp_seq=166 ttl=64 time=6.36 ms
64 bytes from 192.168.4.9: icmp_seq=167 ttl=64 time=6.25 ms
64 bytes from 192.168.4.9: icmp_seq=168 ttl=64 time=21.1 ms
64 bytes from 192.168.4.9: icmp_seq=169 ttl=64 time=9.23 ms
64 bytes from 192.168.4.9: icmp_seq=170 ttl=64 time=10.3 ms
64 bytes from 192.168.4.9: icmp_seq=171 ttl=64 time=50.6 ms
64 bytes from 192.168.4.9: icmp_seq=172 ttl=64 time=7.40 ms
64 bytes from 192.168.4.9: icmp_seq=173 ttl=64 time=125 ms
64 bytes from 192.168.4.9: icmp_seq=174 ttl=64 time=6.32 ms
64 bytes from 192.168.4.9: icmp_seq=175 ttl=64 time=9.14 ms
64 bytes from 192.168.4.9: icmp_seq=176 ttl=64 time=47.4 ms
64 bytes from 192.168.4.9: icmp_seq=177 ttl=64 time=6.50 ms
64 bytes from 192.168.4.9: icmp_seq=178 ttl=64 time=7.61 ms
64 bytes from 192.168.4.9: icmp_seq=179 ttl=64 time=7.54 ms
64 bytes from 192.168.4.9: icmp_seq=180 ttl=64 time=6.31 ms
64 bytes from 192.168.4.9: icmp_seq=181 ttl=64 time=143 ms
64 bytes from 192.168.4.9: icmp_seq=182 ttl=64 time=6.72 ms
64 bytes from 192.168.4.9: icmp_seq=183 ttl=64 time=5.50 ms
64 bytes from

 192.168.4.9: icmp_seq=184 ttl=64 time=58.6 ms
64 bytes from 192.168.4.9: icmp_seq=185 ttl=64 time=6.29 ms

Mantri’s MacBook Pro_ch1_2024-08-20_23.17.41.413.pcap.zip

Block ack is still fine in this log. Right now, I use phone as station to softap (as laptop need to sniff). But phone when screen getting deem, typically starts to increase the ping RTT.

Here ping from AP (Raspberry pi) to phone IP was made (reverse direction, but shouldn't matter)

We might need to repeat the test with two stations, as phone is not the correct station to test with. Even as phone gets connections it starts to pump a lot of data, identifies the network connections is not available, auto redirects to normal router connection, leaving the esp softap.

ShengjieCh commented 2 months ago

When I tested it, I turned on the phone screen to stay on / turned on performance mode / turned off WLAN scanning. And compared it with other wifi chips (such as Broadcom/UNISOC), there was no problem of sudden increase in ping RTT.

mantriyogesh commented 2 months ago

I think it is important, to define scope of the issue.

Can you please let us know if sta mode and softap mode or both are the areas you face the issues?

ShengjieCh commented 2 months ago

My usage scenario is that esp32 acts as soft-ap / 20M bandwidth / channel 10, and the mobile phone acts as a station to connect to the esp32.

mantriyogesh commented 2 months ago

Can you please confirm this is correct?

https://github.com/espressif/esp-hosted/issues/457#issuecomment-2293031813

ShengjieCh commented 2 months ago

I'm sure this is correct, and I also can't decrypt it. image

mantriyogesh commented 2 months ago

Now I am not sure which idf example you have run this, but from the log, it looks like it is have you also tested the softap example with icmp_echo?

Anyway, I tested the ping integrated in default esp-idf iperf example (native, i.e. non-esp-hosted) and found below result over the air test:

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x1974
load:0x4086c110,len:0x1018
load:0x4086e610,len:0x2f68
entry 0x4086c11a
I (23) boot: ESP-IDF v5.4-dev-1915-g15514919c9-dirty 2nd stage bootloader
I (24) boot: compile time Aug 21 2024 11:52:48
I (25) boot: chip revision: v0.0
I (29) qio_mode: Enabling default flash chip QIO
I (34) boot.esp32c6: SPI Speed      : 80MHz
I (39) boot.esp32c6: SPI Mode       : QIO
I (43) boot.esp32c6: SPI Flash Size : 2MB
I (48) boot: Enabling RNG early entropy source...
I (54) boot: Partition Table:
I (57) boot: ## Label            Usage          Type ST Offset   Length
I (64) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (72) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (79) boot:  2 factory          factory app      00 00 00010000 00100000
I (87) boot: End of partition table
I (91) esp_image: segment 0: paddr=00010020 vaddr=420a8020 size=29ff8h (172024) map
I (134) esp_image: segment 1: paddr=0003a020 vaddr=40800000 size=05ff8h ( 24568) load
I (141) esp_image: segment 2: paddr=00040020 vaddr=42000020 size=a0dc0h (658880) map
I (274) esp_image: segment 3: paddr=000e0de8 vaddr=40805ff8 size=1b524h (111908) load
I (300) esp_image: segment 4: paddr=000fc314 vaddr=40821520 size=03b04h ( 15108) load
I (312) boot: Loaded app from partition at offset 0x10000
I (312) boot: Disabling RNG early entropy source...
I (324) cpu_start: Unicore app
I (332) cpu_start: Pro cpu start user code
I (333) cpu_start: cpu freq: 160000000 Hz
I (333) app_init: Application information:
I (335) app_init: Project name:     iperf
I (340) app_init: App version:      qa-test-full-master-esp32c5-202
I (347) app_init: Compile time:     Aug 21 2024 11:53:25
I (353) app_init: ELF file SHA256:  bd02ecc2c...
I (358) app_init: ESP-IDF:          v5.4-dev-1915-g15514919c9-dirty
I (365) efuse_init: Min chip rev:     v0.0
I (370) efuse_init: Max chip rev:     v0.99
I (375) efuse_init: Chip rev:         v0.0
I (380) heap_init: Initializing. RAM available for dynamic allocation:
I (387) heap_init: At 4082AAC0 len 00051B50 (326 KiB): RAM
I (393) heap_init: At 4087C610 len 00002F54 (11 KiB): RAM
I (399) heap_init: At 50000000 len 00003FE8 (15 KiB): RTCRAM
I (406) spi_flash: detected chip: generic
I (410) spi_flash: flash io: qio
W (414) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (427) sleep: Configure to isolate all GPIO pins in sleep state
I (434) sleep: Enable automatic switching of GPIO sleep configuration
I (441) coexist: coex firmware version: 8da3f50af
I (456) coexist: coexist rom version 5b8dcfa
I (456) main_task: Started on CPU0
I (456) main_task: Calling app_main()
I (464) pp: pp rom version: 5b8dcfa
I (464) net80211: net80211 rom version: 5b8dcfa
I (470) wifi:wifi driver task: 40834b08, prio:23, stack:6656, core=0
I (475) wifi:wifi firmware version: 5ad280023
I (479) wifi:wifi certification version: v7.0
I (483) wifi:config NVS flash: disabled
I (486) wifi:config nano formatting: disabled
I (491) wifi:mac_version:HAL_MAC_ESP32AX_761,ut_version:N, band mode:0x1
I (497) wifi:Init data frame dynamic rx buffer num: 60
I (502) wifi:Init static rx mgmt buffer num: 5
I (506) wifi:Init management short buffer num: 32
I (510) wifi:Init dynamic tx buffer num: 40
I (514) wifi:Init static tx FG buffer num: 2
I (518) wifi:Init static rx buffer size: 1700 (rxctrl:92, csi:512)
I (525) wifi:Init static rx buffer num: 40
I (528) wifi:Init dynamic rx buffer num: 60
I (532) wifi_init: rx ba win: 32
I (536) wifi_init: accept mbox: 6
I (540) wifi_init: tcpip mbox: 64
I (544) wifi_init: udp mbox: 64
I (548) wifi_init: tcp mbox: 64
I (551) wifi_init: tcp tx win: 51200
I (556) wifi_init: tcp rx win: 65535
I (560) wifi_init: tcp mss: 1440
I (564) wifi_init: WiFi IRAM OP enabled
I (568) wifi_init: WiFi RX IRAM OP enabled
I (573) wifi_init: WiFi SLP IRAM OP enabled
I (578) wifi_init: LWIP IRAM OP enabled
I (583) wifi:set country: cc=CN schan=1 nchan=13 policy=0

I (588) wifi:Set ps type: 0, coexist: 0

I (592) phy_init: phy_version 310,dde1ba9,Jun  4 2024,16:38:11
W (644) wifi:ACK_TAB0   :0x   90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (644) wifi:CTS_TAB0   :0x   90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (649) wifi:(agc)0x600a7128:0xd210ab1c, min.avgNF:0xce->0xd2(dB), RCalCount:0x10a, min.RRssi:0xb1c(-78.25)
W (659) wifi:(TB)WDEV_PWR_TB_MCS0:19
W (662) wifi:(TB)WDEV_PWR_TB_MCS1:19
W (665) wifi:(TB)WDEV_PWR_TB_MCS2:19
W (669) wifi:(TB)WDEV_PWR_TB_MCS3:19
W (672) wifi:(TB)WDEV_PWR_TB_MCS4:19
W (675) wifi:(TB)WDEV_PWR_TB_MCS5:19
W (678) wifi:(TB)WDEV_PWR_TB_MCS6:18
W (682) wifi:(TB)WDEV_PWR_TB_MCS7:18
W (685) wifi:(TB)WDEV_PWR_TB_MCS8:17
W (688) wifi:(TB)WDEV_PWR_TB_MCS9:15
W (692) wifi:(TB)WDEV_PWR_TB_MCS10:15
W (695) wifi:(TB)WDEV_PWR_TB_MCS11:15
I (699) wifi:11ax coex: WDEVAX_PTI0(0x55777555), WDEVAX_PTI1(0x00003377).

I (705) wifi:mode : sta (40:4c:ca:4a:a8:50)
I (709) wifi:enable tsf

 ==================================================
 |       Steps to test WiFi throughput            |
 |                                                |
 |  1. Print 'help' to gain overview of commands  |
 |  2. Configure device to station or soft-AP     |
 |  3. Setup WiFi connection                      |
 |  4. Run iperf to test UDP/TCP RX/TX throughput |
 |                                                |
 =================================================

Type 'help' to get the list of commands.
Use UP/DOWN arrows to navigate through command history.
Press TAB when typing command name to auto-complete.
I (840) main_task: Returned from app_main()
iperf>
iperf> ap_set sample sample@123
I (17274) WIFI: DONE.SET_AP_CONFIG,FAIL.12293,ESP_ERR_WIFI_MODE
iperf> wifi_mode apsta
I (22580) WIFI: mode: apsta
I (22581) wifi:mode : sta (40:4c:ca:4a:a8:50) + softAP (40:4c:ca:4a:a8:51)
W (22582) wifi:11ax/11ac mode can not work under phy bw 40M, the softap 2G bandwidth changed to 20M
I (22593) wifi:Total power save buffer number: 20
I (22593) wifi:Init max length of beacon: 752/752
I (22604) wifi:Init max length of beacon: 752/752
I (22605) esp_netif_lwip: DHCP server started on interface WIFI_AP_DEF with IP: 192.168.4.1
I (22605) WIFI: DONE.SET_WIFI_MODE,OK.
iperf> ap_set sample sample@123
I (24417) wifi:Total power save buffer number: 20
I (24418) esp_netif_lwip: DHCP server started on interface WIFI_AP_DEF with IP: 192.168.4.1
I (24419) WIFI: DONE.SET_AP_CONFIG,OK.
iperf>
iperf> I (34470) wifi:new:<1,0>, old:<1,0>, ap:<1,0>, sta:<0,0>, prof:1, snd_ch_cfg:0x0
I (34471) wifi:(trc)phytype:CBW20-SGI, snr:54, maxRate:0, highestRateIdx:0
W (34482) wifi:(trc)band:2G, phymode:3, highestRateIdx:0, lowestRateIdx:11, dataSchedTableSize:14
I (34483) wifi:(trc)band:2G, rate(S-MCS7, rateIdx:0), ampdu(rate:S-MCS7, schedIdx(0, stop:8)), snr:54, ampduState:wait operational
I (34494) wifi:ifidx:1, rssi:-28, nf:-82, phytype(0x3, CBW20-SGI), phymode(0x3, 11bgn), max_rate:0, he:0, vht:0, ht:1
I (34505) wifi:(ht)max.RxAMPDULenExponent:3(65535 bytes), MMSS:6(8 us)
I (34516) wifi:station: a4:cf:99:50:73:55 join, AID=1, bgn, 20
W (34610) wifi:<ba-add>idx:4, ifx:1, tid:6, TAHI:0x1015573, TALO:0x5099cfa4, (ssn:0, win:64, cur_ssn:0), CONF:0xc0006005
I (34611) esp_netif_lwip: DHCP server assigned IP to a client, IP is: 192.168.4.2
I (34623) wifi:[ADDBA]TX addba request, tid:0, dialogtoken:1, bufsize:64, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0)
I (34642) wifi:[ADDBA]RX addba response, status:0, tid:0/tb:1(0xa1), bufsize:32, batimeout:0, txa_wnd:32
W (35847) wifi:<ba-add>idx:5, ifx:1, tid:0, TAHI:0x1015573, TALO:0x5099cfa4, (ssn:2, win:64, cur_ssn:2), CONF:0xc0000005
iperf>
iperf>
iperf>
iperf>
iperf> ping 192.168.4.2
64 bytes from 192.168.4.2: icmp_seq=1 ttl=64 time=4 ms
iperf> 64 bytes from 192.168.4.2: icmp_seq=2 ttl=64 time=4 ms
64 bytes from 192.168.4.2: icmp_seq=3 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=4 ttl=64 time=4 ms
64 bytes from 192.168.4.2: icmp_seq=5 ttl=64 time=6 ms

--- 192.168.4.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 20ms
iperf>
iperf> ping -c 20 192.168.4.2
64 bytes from 192.168.4.2: icmp_seq=1 ttl=64 time=69 ms
iperf> 64 bytes from 192.168.4.2: icmp_seq=2 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=3 ttl=64 time=15 ms
64 bytes from 192.168.4.2: icmp_seq=4 ttl=64 time=7 ms
64 bytes from 192.168.4.2: icmp_seq=5 ttl=64 time=10 ms
64 bytes from 192.168.4.2: icmp_seq=6 ttl=64 time=10 ms
64 bytes from 192.168.4.2: icmp_seq=7 ttl=64 time=5 ms
64 bytes from 192.168.4.2: icmp_seq=8 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=9 ttl=64 time=64 ms
64 bytes from 192.168.4.2: icmp_seq=10 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=11 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=12 ttl=64 time=25 ms
64 bytes from 192.168.4.2: icmp_seq=13 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=14 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=15 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=16 ttl=64 time=20 ms
64 bytes from 192.168.4.2: icmp_seq=17 ttl=64 time=46 ms
64 bytes from 192.168.4.2: icmp_seq=18 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=19 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=20 ttl=64 time=3 ms

--- 192.168.4.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 297ms
iperf>
iperf> ping -c 40 192.168.4.2
64 bytes from 192.168.4.2: icmp_seq=1 ttl=64 time=58 ms
iperf> 64 bytes from 192.168.4.2: icmp_seq=2 ttl=64 time=97 ms
64 bytes from 192.168.4.2: icmp_seq=3 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=4 ttl=64 time=8 ms
64 bytes from 192.168.4.2: icmp_seq=5 ttl=64 time=8 ms
64 bytes from 192.168.4.2: icmp_seq=6 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=7 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=8 ttl=64 time=49 ms
64 bytes from 192.168.4.2: icmp_seq=9 ttl=64 time=76 ms
64 bytes from 192.168.4.2: icmp_seq=10 ttl=64 time=4 ms
64 bytes from 192.168.4.2: icmp_seq=11 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=12 ttl=64 time=43 ms
64 bytes from 192.168.4.2: icmp_seq=13 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=14 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=15 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=16 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=17 ttl=64 time=9 ms
64 bytes from 192.168.4.2: icmp_seq=18 ttl=64 time=7 ms
64 bytes from 192.168.4.2: icmp_seq=19 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=20 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=21 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=22 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=23 ttl=64 time=2 ms
64 bytes from 192.168.4.2: icmp_seq=24 ttl=64 time=1 ms
64 bytes from 192.168.4.2: icmp_seq=25 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=26 ttl=64 time=11 ms
64 bytes from 192.168.4.2: icmp_seq=27 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=28 ttl=64 time=18 ms
64 bytes from 192.168.4.2: icmp_seq=29 ttl=64 time=5 ms
64 bytes from 192.168.4.2: icmp_seq=30 ttl=64 time=8 ms
64 bytes from 192.168.4.2: icmp_seq=31 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=32 ttl=64 time=10 ms
64 bytes from 192.168.4.2: icmp_seq=33 ttl=64 time=35 ms
64 bytes from 192.168.4.2: icmp_seq=34 ttl=64 time=59 ms
64 bytes from 192.168.4.2: icmp_seq=35 ttl=64 time=67 ms
64 bytes from 192.168.4.2: icmp_seq=36 ttl=64 time=107 ms
64 bytes from 192.168.4.2: icmp_seq=37 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=38 ttl=64 time=52 ms
64 bytes from 192.168.4.2: icmp_seq=39 ttl=64 time=3 ms
64 bytes from 192.168.4.2: icmp_seq=40 ttl=64 time=4 ms

--- 192.168.4.2 ping statistics ---
40 packets transmitted, 40 received, 0% packet loss, time 787ms

I confirm the issue. But the issue seems to also seem to be present in ap mode from esp-idf as well. Again, these tests are over the air, so many things might be need to narrow down to localise the issue.

ESP-Hosted also adds jitter, which is unavoidable, but anyone aat least would expect the jittter should be constant difference (for SPI overhead, ESP-Hosted - slave-host software).

This case might need good debugging and cannot commit that tthis would solve in a day or so.

mantriyogesh commented 2 months ago

@kapilkedawat , I think we may need wifi driver team assistance in this.

mantriyogesh commented 2 months ago

By the way, I just wanted to complete the discussion around command. https://github.com/espressif/esp-hosted/issues/457#issuecomment-2291045054.

by the logs, I can confirm, Screenshot 2024-08-21 at 12 11 30 PM that this test performed by you was performed with station mode, where ESP-Hosted also do not observe any issues. Please clarify the same from your side @ShengjieCh .

Issue now localised on softap mode. Please help confirming @ShengjieCh .

ShengjieCh commented 2 months ago

By the way, I just wanted to complete the discussion around command. #457 (comment).

by the logs, I can confirm, Screenshot 2024-08-21 at 12 11 30 PM that this test performed by you was performed with station mode, where ESP-Hosted also do not observe any issues. Please clarify the same from your side @ShengjieCh .

Issue now localised on softap mode. Please help confirming @ShengjieCh .

Yes, I used esp32c3 as station mode to do this test, and it is indeed different here. I will test it in soft-ap mode later.

mantriyogesh commented 2 months ago

I am not sure of block ack failure, although, may be you can try with some other device. Or else you can get a fresh sniffer capture. If it is feasible for you, you can also test the example I had tested in https://github.com/espressif/esp-hosted/issues/457#issuecomment-2300724112 and get the capture and upload your findings on ESP-IDF itself, with reference to current ESP-Hosted issue.

We are anyway internally consulting the Wi-Fi driver team, to reproduce this idf example problem in shield box environment, which would be a better way to assess.

ShengjieCh commented 2 months ago

https://github.com/espressif/esp-idf/blob/master/examples/protocols/icmp_echo/main/echo_example_main.c

It is found that block ack is repeatedly requested and deleted image This block ack establishment failure problem cannot be reproduced on your side. What configurations may cause this problem? The firmware I use is the official firmware: image The upper layer configures these options: image

mantriyogesh commented 2 months ago

Please try over latest master. I am not entirely sure why the block acks should fail anyway. in the sniffer I had attached, you can observe block acks are working fine.

You can use ESP-IDF on master and ESP-Hosted on latest. But in any case, this is very basic thing to work as such, and it is supported since long.

Is any any config changes that you have done manually?