Sched is requesting more input data than we can provide

GNU Radio
1

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

2

-----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/

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

3

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
[email protected]
Discuss-gnuradio Info Page

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

4

Hi Marcus,

On Thu, Jan 23, 2014 at 10:12 PM, Marcus Müller [email protected]
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

5

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

6

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

7

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

8

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.

9

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

10

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

11

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. [email protected]:

12

On Sun, Feb 8, 2015 at 5:44 AM, You L. [email protected]
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