Evaluate the need of the fourth thread
denis-stepanov opened this issue · 1 comments
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.
After detailed measurements the "imperfections in timing" have been confirmed. There are at least these sources of additional delay:
- 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;
- 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.