The value is in bytes. Set it to something like 1048576 (2^20).

On Thu, Sep 16, 2021 at 9:25 AM Armin Ghani <[email protected]> wrote:

> I tried to change minoutbuf size of the block before block
> ofdm_serializer_vcc to 241 (I set 241 because 240 produces error so I
> concluded that final size is N-1). The error vanished but a new one is
> produced:
>
> set_min_output_buffer on block 36 to 241
> thread[thread-per-block[36]: <block ofdm_serializer_vcc(30)>]: Buffer too
> small for min_noutput_items
>
> So the question is what Buffer is exactly refered to in this message? How
> is that to increase that buffer?
> On 16/9/21 14:04, Jeff Long wrote:
>
> 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
>>
> --
>
> 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
>

Reply via email to