Re: [Discuss-gnuradio] block is requesting more input data than it can provide

[Martin Braun]

On 02/28/2014 01:17 AM, Rob Miller wrote:
> Rather than posting a rather complicated flowgraph, I was able to
> re-create the error that I'm seeing with a much simpler flowgraph.  A
> screen cap from from grc file, and the grc file itself are attached.  In
> the example, there are still two data paths, coming from two sources.
>  In one path, the two sources are simply summed.  In the other path, the
> two sources go through keep_m_in_n blocks before being multiplied
> together (this path mimics the more computationaly complex path).  In
> this example, the 'm' is set to 750e3, and the 'n' is an integer
> multiple of 'm'.  'NBUF' is the multiplier used in the flow graph, such
> that 'n = m*NBUF'.  When I set NBUF to 2 or below, things run.  When
> NBUF is set to 3 (or higher) the flowgraph does not run, and I get the
> following error for each keep_m_in_n block (for NBUF=3):

You get that same error even if you just connect the keep-block to a
null sink and source.

> sched: <block keep_m_in_n (7)> is requesting more input data
>   than we can provide.
>   ninput_items_required = 2250000
>   max_possible_items_available = 1500159
>   If this is a filter, consider reducing the number of taps.
> 
> So, it seems that the max items available can accommodate just over
> NBUF=2 (which would be 1.5e6 samples).  As a note, I'm running GNU Radio
> 3.7 under Ubuntu 12.04 (64-bit).  I've also double-checked my
> sysctl.conf settings (e.g. shmmax) and they appear to be ok (I'm using a
> very capable, multi-core server).  Searching through some old posts, I
> happened upon:

Even with a large shmmax, buffer sizes are ultimately limited.

> http://gnuradio.4.n7.nabble.com/sched-is-requesting-more-input-data-than-we-can-provide-td45898.html
> 
> , which shows a similar problem.  The resolution was to use
> set_relative_rate, but I'm not sure how I would do that within grc?
>  Further, when I replace the keep_m_in_n blocks with decimators
> (specifically the Decimating FIR Filter), and use NBUF as the
> decimation, then everything runs just fine.  Am I simply doing something
> very silly?  Is there a better recommendation for the flowgraph
> architecture?

keep_m_in_n uses set_output_multiple() and hardcodes the relative rate
in forecast(). This makes the general_work() function very easy to
implement, since both the input and output buffer are already aligned to
the data.
The block wasn't designed for massive buffers like you need. This would
require rewriting the block to keep states, and simply operate on as
much buffer space is available. For small n and m, that might be
inefficient.
If you want to try this, I recommend creating your own keep-block in an
OOT, copying the code, switching set_output_multiple() to
set_relative_rate() and then adding states to your work function.

I can't see an easy way to do that with stock GR blocks right now.

M