maxoutbuf mean that the buffer can be no bigger than x, minoutbuf means it can be no smaller. Changing minoutbuf on every block should be the same as changing GR_FIXED_BUFFER_SIZE.
On Thu, Sep 16, 2021 at 7:04 AM Armin Ghani <[email protected]> wrote: > Thanks Jeff for your reply. > > Yes, I just changed the values again right now but nothing changed. I set > minoutbuf value from 1 to 10000 increasing 10 times more each time. > > I dont know exactly why you suggested minoutbuf to be changed because what > I understand is that block ofdm_serializer_vcc needs amount of input > which is more than what shceduler can supply. Since number of input needed > comes from number of output items to be produced, I dont get why minoutbuf > is needed to be changed. If we want to make change to have lesser number of > input items needed so we need to limit maxoutbuf instead. That makes more > sense. > On 16/9/21 12:22, Jeff Long wrote: > > Have you tried changing the minimum output buffer on either the block or > the one before it? This can be done in the block parameters under the > advanced tab. There is no reason to redefine GR_FIXED_BUFFER_SIZE, just > change it where necessary. Buffers are on the output of each block. > > On Thu, Sep 16, 2021 at 5:44 AM Armin Ghani <[email protected]> wrote: > >> Dear community >> >> I've been tackling to fix below scheduler error which it fails to >> allocate buffer for blocks: >> >> ched: <block ofdm_serializer_vcc (22)> is requesting more input data >> than we can provide. >> ninput_items_required = 960 >> max_possible_items_available = 127 >> If this is a filter, consider reducing the number of taps. >> >> I'm curious to know how to mitigate such error. This issue has been >> covered very few but one of the workaround would be to change >> GR_FIXED_BUFFER_SIZE as much as the error disappears but this is not a good >> solution since it leads to scheduler sample propagation delays. I welcome >> every effective and reliable solution despite of being difficult to >> implement and etc. >> >> Below there are a few solutions that came to my mind but none of them are >> final solutions: >> >> - Trying to change GR_FIXED_BUFFER_SIZE. This leads to path delays which >> prevents flow graph to run smoothly >> >> - Trying to remove extra blocks. This is not so effective >> >> - Simplifying block implementation specially those which are implemented >> in hier-block approach by writing c++ code instead. This is also not so >> effective >> >> - dividing top-block into smaller top-blocks with fever blocks. Not >> helpful >> >> I'll be more than happy to hear you back. >> >> Regards. >> >> >> -- >> >> Armin Ghani >> >> Research Engineer | Communication Systems Division (CSD) >> >> [email protected] | +34 93 645 29 08 (2143) >> >> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) >> >> Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT >> >> 08860 - Castelldefels (Barcelona, Spain) >> >> www.cttc.cat >> > -- > > Armin Ghani > > Research Engineer | Communication Systems Division (CSD) > > [email protected] | +34 93 645 29 08 (2143) > > Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) > > Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT > > 08860 - Castelldefels (Barcelona, Spain) > > www.cttc.cat >
