Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittent WiFi performance issues #12

Open
evoggy opened this issue May 9, 2022 · 4 comments
Open

Intermittent WiFi performance issues #12

evoggy opened this issue May 9, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@evoggy
Copy link
Member

evoggy commented May 9, 2022

It's been observed that the WiFi suffers from intermittent performance issues. This can be seen in the wifi-img-streaming example where the frame rate sometime goes down and the image stops updating for a short while. This seems to be caused by the WiFi throughput going down, which causes the tx queues in the ESP to fill up and in turn blocks the SPI communication from the GAP8. The same interruptions can be seen client side. The result can be seen below:
ESP32<->GAP8 SPI communication

After some investigation the trail ends at send(...) in wifi.c which runs smoothly most of the time, but can take seconds to return sometimes, and this will backup the queues all the way to the GAP8.

@evoggy evoggy added the bug Something isn't working label May 9, 2022
@whoenig
Copy link
Contributor

whoenig commented Jun 1, 2022

I tested the intermediate fix in #9 (issue also described in https://forum.bitcraze.io/viewtopic.php?t=5321). While it does improve the performance, we are still seeing large gaps in the communication (sometimes up to 3 seconds). For us, this seems to be happening only when routing to multiple targets, i.e., especially if we route messages STM32->GAP8, while streaming data out over wifi.

Perhaps this is a bit off-topic, but why isn't the direct UART connection AI-deck <-> GAP8 being used for CPX? This would reduce this SPI bottleneck mentioned in this issue.

whoenig added a commit to IMRCLab/aideck-gap8-examples that referenced this issue Jun 8, 2022
This avoids a performance issue as detailed in bitcraze/aideck-esp-firmware#12.
At the same time, this should be lower latency than using CPX.

The protocol itself is hard-coded and not as generic as CPX.
@evoggy
Copy link
Member Author

evoggy commented Jun 14, 2022

When I was testing it here I couldn't find any connection between the GAP8<->STM32 communication and these pauses. Even with all the GAP8<->STM32 communication switched off I was still getting these. As to the cause of this I'm not sure, it could also be interoperability issues with our WiFi setup. I'm happy that skipping the GAP8<->STM32 communication seems to work for you.

There's a few reasons for not using the UART between the GAP8 and the STM32:

  • In the first version of the AI deck (1.0) there's a silicon bug on the GAP8 which causes issues with the UART RX, there's a workaround but we haven't implemented this
  • We wanted the UART GAP8<->STM32 to be free for users to use for their own implementation
  • Minimize the code by reusing the same path

I'm hoping to get some time in the coming weeks to look at this (when things wind down for the summer).

@finnfi
Copy link

finnfi commented Jun 21, 2022

I dont have very much to add here, but we have been playing around with the wifi-streaming-example and there was a big performance difference between connecting the cf to my desktop via WiFi and connecting to the one of my colleague. My WiFi driver works fine with other networks, so I am not sure why this happens.

@evoggy
Copy link
Member Author

evoggy commented Jun 21, 2022

Thanks for the feedback. Yeah, I've also seen some differences between my WiFi at home and at the office.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants