Re: [Discuss-gnuradio] sched is requesting more input data than we can provide

[You Lizhao]

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 Maroti <address@hidden>:

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

On Fri, Jan 24, 2014 at 2:00 PM, Martin Braun <address@hidden> wrote:
> On 01/24/2014 07:28 AM, Miklos Maroti 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
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio