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

[Rob Miller]

Hi -
I'm having some trouble configuring a flowgraph. In my flowgraph, there are two paths for data. In one path, the data goes through a gnuradio block that is lightweight enough to process the data in real-time. In the other path, there is a gnuradio block that is much more computationally demanding. My goal is to maintain the real-time operation of the first path (i.e. not have the second path block). For my needs, the second path does not need to run in real-time, nor does it need to operate on all of the data (just sections of it every so often).
I tried to implement this functionality by using a keep_m_in_n block on the more demanding path. In my flowgraph, I made 'n' and integer multiple of 'm', and it works up to a specific multiple that does not meet my needs. In other words, the multiple is not large enough to maintain real-time operation for the first path.
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):
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:
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?
Best,Rob

[Martin Braun]

Post by Rob Miller
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

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

Post by Rob Miller
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

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

Post by Rob Miller
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