Reduce gnss_syncro_monitor CPU load

[vladisslav2011]

For some unknown reason gnss_synchro_monitor stays in a tight loop trying
to catch all syncros and sometimes consumes the whole CPU core.
Triggering the gnss_syncro_monitor from sample counter as it is done
with observables greatly reduces CPU usage from ~60...90% to 1..2%.

CPU usage.

Before:

After:

Fixes #661

[jwmelto]

I can believe that this improves performance (your evidence is compelling) but I'm not sure this is a quality fix. It may be; the case just hasn't been made.

[jwmelto]

I still don't like the brittleness of this approach, but I am not sure there is a better one. I see you had to increment the channels to the ctor of the Acq monitor; the same change is needed (most likely) for the Tracking monitor.

Arguably, this could be moved to the ctor, so callers don't have to remember/know about this "extra" port (this is part of the brittleness; Or, you could just fix the tracking monitor as well.

[vladisslav2011]

Thanks.
I've updated tracking monitor creation/connection.

I see at least 2 different solutions to this problem:

1. Pass synchros to the monitor as messages
2. Modify gnss_synchro_monitor::general_work to sleep for some time if all input buffers are empty

[jwmelto]

Thanks. I've updated tracking monitor creation/connection.

I see at least 2 different solutions to this problem:

1. Pass synchros to the monitor as messages

This would be such a fundamental change to architecture, it's unlikely to be accepted.

2. Modify gnss_synchro_monitor::general_work to sleep for some time if all input buffers are empty

The default scheduler behavior should be to sleep for 250ms; however, I suspect that forecast is subverting this.

I don't have a problem with the time strobe being an input, but the N+1 th is a maintenance burden. I don't know if there is a way to make a different "class" of input, to make it clear that it's different, or worst case, move it to the 0th input. It still creates a brittle reliance on external users to configure it correctly, and it's too easy to get wrong.

[jwmelto]

@carlesfernandez can this be merged?

[wkazubski]

@carlesfernandez can this be merged?

I an using tkhis patch. It reduces CPU load significantly. Without the patch I had load burst to 100% when monitoring is enabled, afer the patch is applied the CPU load is stable 25-30% while receiving GPS L1 signal with rtl-sdr dongle.