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

Evaluate the need of the fourth thread #5

Closed
denis-stepanov opened this issue Aug 8, 2022 · 1 comment · Fixed by #23
Closed

Evaluate the need of the fourth thread #5

denis-stepanov opened this issue Aug 8, 2022 · 1 comment · Fixed by #23
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@denis-stepanov
Copy link
Owner

With default parameters of 3 sec recognition interval and 1 sec shift, it should be sufficient to have just three threads running. The fourth one was added just in case, to cover for imperfections in timing. Practice shows that one of four threads is idling most of the time. Maybe an extra thread should be launched only when interval / shift does not amount to integer.

@denis-stepanov denis-stepanov added the enhancement New feature or request label Aug 8, 2022
@denis-stepanov denis-stepanov added this to the v1.2.0 milestone Aug 17, 2022
@denis-stepanov denis-stepanov self-assigned this Aug 17, 2022
@denis-stepanov
Copy link
Owner Author

After detailed measurements the "imperfections in timing" have been confirmed. There are at least these sources of additional delay:

  1. new recognition starts not exactly at 1s shift, but anytime between 1s and 1.1s (because of sleep(0.1) when mutex cannot be taken). This error accumulates with time; but it is not very important for the purpose of the app;
  2. there is a non-negligible "deadband" in Dejavu processing. For every 3s recognition period, the actual recognition takes anytime between 3.2 and 3.5s (on a 4x1200MHz machine). Apparently, the engine just listens for 3s and then does its jobs in the remaining time. So this deadband should be taken into account in calculations --> let's do a code change for this.

As such, the need of the fourth thread is thus confirmed. Measurements show that all four threads have more or less the same load and a duty cycle of around 80%. This looks not bad for a default configuration, keeping system load close to 100% but still leaving some time for OS to do other tasks.

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

Successfully merging a pull request may close this issue.

1 participant