Re: [Discuss-gnuradio] what drives noutput_items passed to forecast?

[Eric Blossom]

On Wed, Feb 27, 2008 at 06:21:17PM -0500, George Nychis wrote:
> Hi all,
>
> I understand the basics that forecast is ensuring the number of input items 
> exist to produce a certain number of output items, but what exactly drives 
> the number of output items that are passed to forecast()?  What drives the 
> scheduler to select this number?
>
> For example, if I run benchmark_rx.py and monitor noutput_items in 
> gr_clock_recovery_mm_ff.cc, it looks like this:
> http://cyprus.cmcl.cs.cmu.edu/tmp/clockr_forecast
>
> But, what drives this noutput_items parameter decision?
>
> Is the scheduler in an iterative process where, with an exponential decay, 
> it asks: "How many input items do i need to produce noutput_items?" ... 
> starting at 2^13, which I'm assuming is some sort of maximum buffer size?
>
> Then, if it does not have enough items, it decreases the noutput_items it 
> is passing exponentially, and asks again... until it has enough input 
> items, then calls work().
>
> Thanks!
> George

For blocks derived from gr_sync_block, gr_sync_interpolator and
gr_sync_interpolator the scheduler knows how to compute noutputs from
ninputs and vice versa, and thus chooses noutputs so as to maximize
the amount of data given to work subject to all other constraints.

For other blocks, there isn't a mechanism for mapping from ninputs to
noutputs, so it does a binary search calling forecast until it finds
the value that processes the most input subject to all other constraints.

The details are in gr_single_threaded_scheduler.cc

The two basic constraints are:

  how much input is available
  how much output space is available

There are additional constraints based on output_multiple, etc.

Eric