[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

keep_m_in_n.grc
Description: Binary data

keep_m_in_n.png
Description: PNG image