# Sched is requesting more input data than we can provide

**URL:** <https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693>\
**Category:** GNU Radio\
**Created:** [January 23, 2014, 10:02pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693 "2014-01-23T22:02:27Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**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:** [January 23, 2014, 10:02pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/1 "2014-01-23T22:02:27Z")

</div>

Hi!

I am getting this error:

sched: is requesting more input data  
than we can provide.  
ninput\_items\_required = 16000  
max\_possible\_items\_available = 8191

and I have no idea how to fix it. Is it possible to request more  
buffer space? Setting the minimum output buffer size seems to have no  
effect for me.

Miklos

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 23, 2014, 10:14pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/2 "2014-01-23T22:14:09Z")

</div>

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1

Hi Miklos,

the problem here is xxx:

On 23.01.2014 22:00, Miklos M. wrote:

> sched: is requesting more input data

what’s this xxx? It is requiring 16000 input items at once _at least_  
and that’s nearly twice the max output size (see  
gnuradio-runtime/lib/block\_executor.cc), and you’re right, that has  
something to do with maximum buffer sizes.  
However, GNU Radio has algorithms to appropriately set up buffers to  
make the items flow. Unless you’ve configured the top\_block  
explicitely to have max noutput items \< 16000, that should work out  
unless there is some architectural quirk in your flowgraph that  
actually suggest that it /can’t/ run.

So, to help you out, we actually need a little more information.  
Most probably an architectural change to xxx or your flowgraph will  
solve your problem.

Greetings,  
Marcus  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1  
Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/)

iQEcBAEBAgAGBQJS4YW+AAoJEAFxB7BbsDrLQlUH/0A0+QTTNSaun4ML91BKMbAy  
ga9wFwJQRLlR1CJewzGBHzAJhx7ruSSh3P3H4jEJb7Lg5zpHAUQ/qB7+AspobFZt  
HsYgmApPGv6ck0DyEe5SNiKKPr8HNCvf9t/hijBd8yNOWrPrjcDTR1GJQfy69yYJ  
oX11Y+1IOSFQI0mL6dKkcIJ6Q9tEV2J0qRQieLxF4CqO5dSLQ1W9HtfElVktrJ18  
a3BcxNhJLppKMZqlBwMommQCcoZ1+3J1KWlTxPP0dj58reEN9ub0vRKa98KtFXZI  
AbMWP1jaJrjDIgvRRPIU1txbKMIh4V77N1bg4fF0elHVD+5QAgh3HdiVQhyVPOU=  
=3zBJ  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 23, 2014, 10:14pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/3 "2014-01-23T22:14:09Z")

</div>

On 01/23/2014 04:00 PM, Miklos M. wrote:

> buffer space? Setting the minimum output buffer size seems to have no  
> effect for me.
> 
> Miklos
> 
> * * *
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

If this isn’t a block you wrote yourself, it’s very likely that you’ve  
misconfigured your flow-graph in a way that causes this to happen. Make  
sure that there’s agreement about sample-rates, decimations, etc,  
throughout the graph.

–  
Marcus L.  
Principal Investigator  
Shirleys Bay Radio Astronomy Consortium

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 24, 2014, 7:30am UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/4 "2014-01-24T07:30:20Z")

</div>

Hi Marcus,

On Thu, Jan 23, 2014 at 10:12 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> what’s this xxx? It is requiring 16000 input items at once _at least_  
> and that’s nearly twice the max output size (see  
> gnuradio-runtime/lib/block\_executor.cc), and you’re right, that has  
> something to do with maximum buffer sizes.  
> However, GNU Radio has algorithms to appropriately set up buffers to  
> make the items flow. Unless you’ve configured the top\_block  
> explicitely to have max noutput items \< 16000, that should work out  
> unless there is some architectural quirk in your flowgraph that  
> actually suggest that it /can’t/ run.

I did not set anything explicitly, although I did not set in my xxx  
block the set relative rate (maybe that is used by the scheduler to  
set up the buffer sizes appropriately).

Basically I want to take 100 packets of size 160 and push them through  
an S/P converter for an 128 point IFFT (think of OFDM where every  
subcarrier would carry its own packets independently).

Miklos

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 25, 2014, 12:08pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/5 "2014-01-25T12:08:55Z")

</div>

Hi Martin,

Ok, I think I have fixed the problem. I did not set the relative rate  
properly in the constructor. It seems, that the scheduler uses the  
relative rates to allocate buffers before the graph is executed, and  
if some block is requesting more data at runtime, then we get into  
problems. It is good to know.

I wonder if I can set the relative rate differently for different  
input streams… but I could not find anything.

Best,  
Miklos

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 24, 2014, 2:02pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/6 "2014-01-24T14:02:49Z")

</div>

On 01/24/2014 07:28 AM, Miklos M. wrote:

> > I did not set anything explicitly, although I did not set in my xxx  
> > block the set relative rate (maybe that is used by the scheduler to  
> > set up the buffer sizes appropriately).
> 
> > Basically I want to take 100 packets of size 160 and push them through  
> > an S/P converter for an 128 point IFFT (think of OFDM where every  
> > subcarrier would carry its own packets independently).
> 
> > Miklos

We still need to know the precise blocks and flow graph configuration.

MB

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 25, 2014, 2:45pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/7 "2014-01-25T14:45:00Z")

</div>

On 01/25/2014 02:23 PM, Miklos M. wrote:

> One more question:
> 
> Can I change the relative rate (with set\_relative\_rate) while the  
> flowgraph is running? What effect does that have?

Yes, you can. As you said, the relative rate is a pointer for the  
scheduler to figure out how much stuff you need at input for a given  
output. You can change it at runtime, and it will still do just that.

MB

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 25, 2014, 2:25pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/8 "2014-01-25T14:25:07Z")

</div>

One more question:

Can I change the relative rate (with set\_relative\_rate) while the  
flowgraph is running? What effect does that have?

Miklos

On Sat, Jan 25, 2014 at 12:07 PM, Miklos M.

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 25, 2014, 3:00pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/9 "2014-01-25T15:00:42Z")

</div>

Hi Martin,

But the buffers are already allocated, and I assume that they are not  
resized dynamically. So even if you change the relative rate at  
runtime, you will get into the “sched: is requesting more input  
data than we can provide” error. So I do not understand how the  
scheduler is going to use the relative rate info WHILE the flowgraph  
is running. I assume it uses only the forecast method only, no?

Miklos

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [January 25, 2014, 4:21pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/10 "2014-01-25T16:21:56Z")

</div>

On 01/25/2014 02:59 PM, Miklos M. wrote:

> Hi Martin,
> 
> But the buffers are already allocated, and I assume that they are not  
> resized dynamically. So even if you change the relative rate at  
> runtime, you will get into the “sched: is requesting more input  
> data than we can provide” error. So I do not understand how the  
> scheduler is going to use the relative rate info WHILE the flowgraph  
> is running. I assume it uses only the forecast method only, no?

Miklos,

no, buffers aren’t changed. The scheduler uses relative\_rate() for a  
couple of things: To guess good values for noutput\_items and input  
buffers (only for sinks, IIRC), also for automatic tag propagation.  
The standard gr::block() implementation assumes a 1:1 relationship in  
forecast(), regardless of relative\_rate(). There are other things that  
are considered, such as set\_output\_multiple().

You can use relative\_rate() yourself, too, e.g. in forecast().

MB

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [February 8, 2015, 11:46am UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/11 "2015-02-08T11:46:10Z")

</div>

Hi Maroti and Braun,

I ran into a similar problem. I tried to set the  
ninput\_items\_required[i] =  
10000, then the same output

sched: \<gr\_block XXX\> is requesting more input data  
than we can provide.  
ninput\_items\_required = 10000  
max\_possible\_items\_available = 8191  
If this is a filter, consider reducing the number of taps.

If I use the default scheduler without setting ninput\_items\_required  
with a  
fixed value in forecast (i.e., ninput\_items\_required[i]=noutput\_items \*  
80), then the program is ok. But I noticed that sometimes the scheduler  
could allocate more than 8191 input items. In this case, my program runs  
into errors.

Two questions:  
(1) Why sometimes the default scheduler can return more than 8191 items,  
and we could not set it manually?  
(2) Do you have any idea of how max\_possible\_items\_available = 8191  
comes?  
If it is related to set\_relative\_rate, then it is weird 8191/128=63.99.

I used GNURadio v3.6.5.1. Really appreciate your help.

Regards,  
Lizhao

2014-01-25 19:07 GMT+08:00 Miklos M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Miklos\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@Miklos\_M](https://www.ruby-forum.com/u/Miklos_M)\
**Post date:** [February 9, 2015, 3:16pm UTC](https://www.ruby-forum.com/t/sched-is-requesting-more-input-data-than-we-can-provide/238693/12 "2015-02-09T15:16:53Z")

</div>

On Sun, Feb 8, 2015 at 5:44 AM, You L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> If it is related to set\_relative\_rate, then it is weird 8191/128=63.99.
> 
> I used GNURadio v3.6.5.1. Really appreciate your help.
> 
> Regards,  
> Lizhao

There’s a complicated algorithm that determines the size of the buffers  
based on a handful of other settings of the block. You can try to use  
the  
set\_min\_output\_buffer function call in the block to increase the size of  
the buffer, but this might have unintended consequences for the runtime.

Tom