I will ask a question for the first time. I'm sorry if my manners were wrong.
I used RedHawkSDR v1.10.1 on embedded Linux on Xilinx Zynq. AM demodulation processing is implemented with waveform connected three components. When connecting the Ether and monitoring the waveform, since abnormal noise appears in the received sound, We upgraded to RedHawkSDR v2.1.0. GPP changed from python to C ++ and I thought that I could expect better performance. However, when RedHawkSDR v2.1.0 was adopted, it became to be further strange. Looking at the cause, GPP intensively operates every threshold_cycle_time, Demodulation processing was not completed. It seems that abnormal sound comes out at the timing when GPP acquires information such as CPU / NIC etc. and threshold is judged. Is there any way to reduce or eliminate the GPP information acquisition process? Environment is below. CPU：Xilinx Zynq ARM CoretexA9 2cores 600MHz OS：Embedded Linux Kernel 3.14 RealTimePatch FrameLength：5.333ms（48kHz sampling, 256 data)
GPP scrapes /proc for all processes related to REDHAWK, providing you with a lot of information (through the utilization property) as well as better control regarding the state of the host. This process can be expensive on resource-limited systems (like the one you're using). You can change how often the update happens by changing the GPP's threshold_cycle_time. If you add the elements:
<componentproperties>
<simpleref refid="threshold_cycle_time" value="2000"/>
</componentproperties>
to the GPP componentplacement element in the DCD, the threshold cycle time is increased from 500 milliseconds (the default) to 2 seconds. The number is an unsigned long, so you can increase this delay to over 4 million seconds
Note that if this threshold is set such that the state of the device does not get updated based on the state of the processor, it will never reach a BUSY state because of the processor use, so it will allow the deployment of applications over-subscribed computing hardware