Re: sample rate with selector and throttle blocks

Rick,

Got it. I understand your question better now. I can't give you a fully confident answer to this, but here is an answer nonetheless. If you look at the code for the throttle block (linked below), you will see it calls "std::this_thread::sleep_until(some_time)" as the mechanism for CPU throttling. Since this call is in it's "work" function, it leads me to believe that the throttle block should only have an effect on the flowgraph if it has samples to process at the input. Otherwise, the work function will never get invoked by the scheduler. 

https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/throttle_impl.cc

While this logic seems sound to me, I recall some discussion many years ago along the lines of "if the throttle block exists anywhere in the flowgraph, then it has an effect". Maybe this was never true, or is out-dated information. Hopefully someone can add to my answer more confidently.

Rich

On Thu, May 29, 2025 at 11:26 AM Rick Smegal <rsmegal@aardvarr.ca> wrote:

Correction: ''path holding throttle block" should be "path holding the
null sink".


On 2025-05-29 11:22, aardric via "GNU Radio, the Free & Open-Source
Toolkit for Software Radio" wrote:
> Richard,
>
>      Thanks for the quick reply. I understand the need for a throttle.
> However, in my case, if the selector block selects the path holding the
> throttle block then the hardware does not appear to throttle which makes
> sense because the hardware isn't being fed data; in this case the CPU
> then runs wild.  I am seeking confirmation that reciprocity holds in
> that if the throttle block is not receiving a stream of data (not in the
> active path), it will then have no impact and the hardware will
> determine the actual sample rate.
>
>
> Rick
>
> On 2025-05-29 11:13, Richard Bell wrote:
>> Hello,
>>
>> TLDR: If you are using hardware in your flowgraph, which I think you
>> are, then you should not include a throttle block. Only use throttle
>> blocks in flowgraphs with no hardware limitations (i.e. reading from
>> files or generating synthetic data on the fly).
>>
>> The throttle block is intended for software only scenarios, in which
>> you want to limit the rate at which your CPU gets called to make
>> computations. The throttle block simply invokes a call to sleep to
>> artificially "throttle" the CPU usage. It is not related to the
>> contextual sample rate of the underlying stream of data. Using a
>> throttle block with hardware can cause unintended issues where you
>> can't keep up with the rate of the hardware.
>>
>> For example, I could record data to a file from a radio with a sample
>> rate of 1 Msps. If I play back that file and plot it in GNU Radio, I
>> could use a throttle with any rate I want to limit CPU usage, but the
>> underlying sample rate of that data will always be 1 Msps. The rate of
>> CPU usage and the underlying sample rate of data are not coupled.
>>
>> Richard
>>
>>
>>
>> On Thu, May 29, 2025 at 10:57 AM aardric via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:
>>
>>      Hi,
>>
>>         Could someone please confirm my understanding that the sample
>>      rate in
>>      the attached flow graph will be determined by the active path of the
>>      second (from left) selector block and NOT the throttle block (that
>>      is,
>>      if throttle not selected)?  This would be consistent with the block
>>      documentation for the selector block on the wiki.
>>
>>
>>      Rick
>>