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

Rapidly (10ms) firing _retransmitTimer causes high CPU usage #96

Open
endreszabo opened this issue Oct 9, 2020 · 1 comment
Open

Rapidly (10ms) firing _retransmitTimer causes high CPU usage #96

endreszabo opened this issue Oct 9, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@endreszabo
Copy link
Contributor

  • I'm submitting a ...
    [ ] bug report
    [x] feature request
    [ ] question about the decisions made in the repository
    [ ] question about how to use this project

  • Summary

I'm running this lib in a simple script on a relatively low performance Raspberry PI and after a week of runtime I noticed that the node processes using atem-connection has high (8% average) overall CPU usage. Here is my proposal.

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

I dug down deep and found that this timer called _retransmitTimer fires every 10 milliseconds a function called _checkForRetransmit to check if there is any packets to resend (or reconnect if stuck, etc).

Since all its logic depends on the members of the _inFlight array, I would kindly ask to enable the timer only when there are actual packets referenced in this array, and close() it once all packets are sent. This would also affect the startTimers function which creates this timer right after connecting. This way we can spare CPU time.

If busy I'm happy to create a PR later but first I'll have to get familiar with TS.

@Julusian
Copy link
Member

What model of pi are you using here? On a pi4 I am seeing around 2% usage of a single core, so not a very significant load.

My only concern with this is that it will mean we have to be very careful to ensure the timer gets started and stopped at the right times. That said I'm not opposed to this, but it'll need to be well tested before being merged into a release version

@Julusian Julusian added the enhancement New feature or request label Oct 29, 2020
Julusian added a commit that referenced this issue Sep 25, 2023
…96

This is so that it only runs when packets are inflight, and lowers idle cpu usage
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants