# Block is requesting more input data than it can provide **URL:** \ **Category:** GNU Radio\ **Created:** [February 28, 2014, 1:39am UTC](https://www.ruby-forum.com/t/block-is-requesting-more-input-data-than-it-can-provide/239469 "2014-02-28T01:39:00Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [February 28, 2014, 1:39am UTC](https://www.ruby-forum.com/t/block-is-requesting-more-input-data-than-it-can-provide/239469/1 "2014-02-28T01:39:00Z")
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: \ 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](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 ---
**Author:** ![coldtone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/9e8a1a/32.png) [@coldtone](https://www.ruby-forum.com/u/coldtone)\ **Post date:** [February 28, 2014, 9:17am UTC](https://www.ruby-forum.com/t/block-is-requesting-more-input-data-than-it-can-provide/239469/2 "2014-02-28T09:17:58Z")
On 02/28/2014 01:17 AM, Rob M. wrote: > 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. > 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](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