Very high CPU usage on channels without signal or with very weak signal

[KejPi]

This is continuation of the discussion from Issue #69. Summary:

• AbracaDABra under Ubuntu shows very high CPU usage when tuned to channel without signal or with very weak signal that can be barely synchronised.
• When the same signal decoded from RAW file the problem does not occur
• The problem is present with DABSDR 2.1 but also with older versions (without selectivity filter)

@andimik Please add more details if I missed anything and please try with AppImage 2.0 https://github.com/KejPi/AbracaDABra/releases/download/v2.0/AbracaDABra-2.0-x86_64.AppImage

[andimik]

AppImage 2.0 from your link with the xml-file of the very weak signal, maximum is 69% CPU.

Bildschirmaufzeichnung vom 15.03.2023, 16:34:45.webm

With RTLSDR, it's above 100%

Bildschirmaufzeichnung vom 15.03.2023, 16:37:09.webm

[andimik]

And also rtl_tcp has more than 100% CPU (latest version, built from sources) after 2 or 3 seconds.

Bildschirmaufzeichnung vom 15.03.2023, 16:44:55.webm

[KejPi]

To be honest I have no idea what is going on on your system. Could you please share how the threads load the system: top -H -p `pidof AbracaDABra` My laptop CPU is Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz - AbracaDABra does not use more that 35% according to top (no signal).

[andimik]

Maybe related to my AMD® A8-4500m apu with radeon(tm) hd graphics × 4? It's an Lenovo ThinkPad Edge E535

Bildschirmaufzeichnung vom 15.03.2023, 18:14:57.webm

At the moment, 8A and 12B are very difficult to receive this afternoon, but soon after locking, the CPU load goes significantly down.

[KejPi]

Could you please share the raw file? I would like to run profiler with this particular input to see where the problem could be.

EDIT: my analysis shows that selectivity filter increased CPU load significantly. According to that results I would say you should not have problems with DABSDR < 2.1, the CPU load will be high but it should be much lower than with DABSDR 2.1+. If it is not the case then the problem is not the processing itself but something else :-(

[andimik]

This is under Windows, DABSDR v2.0.1. Load is high, but not so extreme.

screen-recorder-wed-mar-15-2023-19-13-05-reformatted-00.00.19.874-00.01.42.409.webm

I wonder if a raw file will help you, but I can record one of course later.

[KejPi]

I am not sure either but I do not know what else to try because I have no theory why the CPU load is so high. It seems that the signal is somehow on the edge so that NULL is detected sometimes but sync is not possible.

[KejPi]

Please try this library. I am curious if and how much it helps.

linux_x86_64.tar.gz

[andimik]

This helps a lot!

Bildschirmaufzeichnung vom 15.03.2023, 23:07:28.webm

I was running it the whole night without crash and with low CPU power (the laptop is not hot) on a very very weak channel (7D) in my case, but I could not catch a signal at the end.

[KejPi]

OK, we moved a bit finally. The high CPU load is caused by frequency sync algorithm, in the library I have shared there is limited range from -5kHz ... 5kHz, by default library searches from -20kHz to +20kHz. I will think about some solution, one option is to reduce the range (maybe configurable from INI file), the other is to split the search but this will lead to slower and also probably less successful sync.

[andimik]

But I am fine with this version. It plays all my muxes with less CPU power, even the difficult ones.

[KejPi]

Could you please try this? It should be less CPU demanding than 2.1.1 but as less as 2.1.2. Could you please also try that you can sync all ensembles. Thanks! linux_x86_64_2.1.3.tar.gz

[andimik]

I can sync all ensembles.

Bildschirmaufzeichnung vom 19.03.2023, 23:23:40.webm

Bildschirmaufzeichnung vom 19.03.2023, 23:26:14.webm

[KejPi]

Thanks, that is a very good news :-) I will use this library in next release. I think this ticket can be closed.