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 <mmar...@math.u-szeged.hu>: > 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 <martin.br...@ettus.com> > 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 > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
