Skip to content

updating the throughput calculation in data_channel_flow_control #659

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

Conversation

recap
Copy link
Contributor

@recap recap commented Mar 10, 2025

looking into #101 and it seems that there is a deadlock (tested on M1 chip) where the write_loop or read_loop randomly blocks indefinitely. The way the throughput is calculated is that it reports a degrading performance.
degrading performance

The actual throughput is not degrading but 0. This PR updates the code to report the throughput of every loop iteration independently.
actual iteration throughput

@recap
Copy link
Contributor Author

recap commented Mar 10, 2025

I have the impression that the deadlock is happening because the requestor and responder are sharing the same tokio runtime. When I modified the offer/answer example to simulate the data_channel_flow_control but using 2 separate processes the deadlock did not materialize.

@recap
Copy link
Contributor Author

recap commented Mar 26, 2025

@rainliu Thanks for reviewing it. Do you need more input from me before merging?

@rainliu rainliu merged commit fd88278 into webrtc-rs:master Mar 27, 2025
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants