Re: [Discuss-gnuradio] self.set_min_noutput_items() is not a valid python command in gnuradio ?

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

On 08.03.2014 03:34, Activecat wrote:
> Dear Marcus,
> 
> 1). The line 299 of gnuradio-runtime/lib/block_executor.cc is: 
> noutput_items = min_available_space(d, m->output_multiple(), 
> m->min_noutput_items());
> 
> If this line shows that set_min_output_items() works on the fly,
> does this also shows set_out_multiple() works on the fly? (just to
> confirm because I do not fully understand the source code).
> 
If set_output_multiple just sets the gr::block's field that
gr::block::output_multiple() returns, then yes, it works for the next
iteration.

> 
> 2). Regarding the returning 0 issue, let me share my experience of 
> experiments. I am creating a custom interpolation block with its
> interpolation factor can be changed on the fly.  Hence it is
> inherited from gr::block.  It has one input port and one output
> port. During runtime, there will be no problem if the
> general_work() return 0, provided it consume a non-zero value. The
> flow graph may become unresponsive when the general_work() return 0
> and consume zero.
> 
> My explanation: Says, the instantaneous interpolation factor is
> 800. The general_work() is now called with noutput_items=699 and
> ninput_items[0]=3. In this case the only correct thing that
> general_work() should do is to consume 0 and return 0.
> 
> But later the general_work() will be repeatedly called again with
> the same arguments, i.e. noutput_items=699 and ninput_items[0]=3.
> In this case again the general_work() has to consume 0 and return
> 0.  This may repeat few thousand rounds, or infinite rounds. When
> this happens the flow graph becomes unresponsive (hang).
> 
> That's why it is important to set_min_output_items() to the
> instantaneous interpolation factor (which is 800), if the
> set_output_multiple() doesn't work on the fly.
> 
> If there is no better workaround, we have to stick to this trick at
> the moment.
> 
Hm, I'd call this a bug, iff (!) your forecast does everything right.
Can you confirm?

> Regards, Activecat
> 
Greetings,
Marcus
> 
> On Fri, Mar 7, 2014 at 6:00 PM, Marcus Müller <address@hidden>
> wrote:
> 
>> Hi Activecat,
>> 
>> to answer question 1): grepping for "min_noutput_items" instantly
>> shows that in gnuradio-runtime/lib/block_executor.cc line 299,
>> your block's min_noutput_items() is called every iteration. If
>> there isn't enough space, the block thread sleeps until there is
>> more. So yes, it works on the fly.
>> 
>> I remember there was something with returning 0, and I know that
>> producing 0 items used to mark a source as done, but this
>> mechanism was commented out about a year ago (l. 483ff, I think
>> for some good reason), but I can't remember that being an issue
>> for a non-source block; have you tried it and did you run into
>> problems?
>> 
>> Greetings, Marcus
>> 
>> 
>> 
>> On 03/07/2014 02:26 AM, Activecat wrote:
>> 
>> Dear Sir,
>> 
>> Let me explain the reason of why to use the function: 
>> set_min_noutput_items().
>> 
>> I am creating a custom interpolator block. Says, the
>> interpolation factor is 1000.  Hence it is important to call 
>> set_output_multiple(1000).
>> 
>> Meanwhile, for this block the interpolation factor depends on
>> Sample Rate (samp_rate). In this flow-graph the samp_rate could
>> be changed by the user during runtime. This means the
>> interpolation factor may change during runtime, and hence we need
>> to call set_output_multile() with different values during runtime
>> !
>> 
>> The problem arisen when there is no guarantee that
>> set_output_multiple() will work if you change it on the fly. 
>> (Refer 
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00504.html)
>>
>>
>> 
The workaround is to use set_min_noutput_items() if it work on the fly.
>> Says, after changing samp_rate, the new interpolation factor is 
>> recalculated as 800. If the set_output_multiple(800) doesn't
>> work, the general_work() can still consume 1 input and produce
>> 800 output if the noutput_items is at least 800. This enables the
>> flow graph continue to work.
>> 
>> If the noutput_items is less than 800, the only correct thing
>> the general_work() can do is to consume_each(0) and return 0.
>> This may be problematic and can cause unforeseen behavior. So it
>> is important to make sure the noutput_items is at least 800.
>> Hence I call: set_min_noutput_items(800)
>> 
>> This means we can make use of set_min_noutput_items() as a
>> workaround, if set_output_multiple() doesn't change on the fly.
>> 
>> The questions are: 1).  Can we use this to change setting on the
>> fly: set_min_noutput_items() 2).  Is there any better workaround
>> for this?
>> 
>> Regards, Activecat
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Mar 6, 2014 at 11:36 PM, Tom Rondeau <address@hidden>
>> wrote:
>> 
>>> On Thu, Mar 6, 2014 at 2:12 AM, Activecat <address@hidden>
>>> wrote:
>>>> Dear Sir,
>>>> 
>>>> In c++ we have:  set_min_noutput_items() What is it
>>>> equivalent syntax in python ?
>>>> 
>>>> I try this: self.set_min_noutput_items()
>>>> 
>>>> Error message: AttributeError:
>>>> 'quadrator_upconverter_python1' object has no
>>> attribute
>>>> 'set_min_noutput_items'
>>>> 
>>>> Note: The self.set_output_multiple() in python seems
>>>> accepted, is it
>>> functional
>>>> ..?
>>>> 
>>>> Regards, Activecat
>>> 
>>> Looks like when this feature was added, it didn't make it into
>>> the block.i swig file. I'll push a patch for this soon.
>>> 
>>> But before you try and use this, be very careful. This is an
>>> advanced issue that's really only meant to be used if you a)
>>> really really need it and b) really really know what you are
>>> doing and why.
>>> 
>>> Tom
>>> 
>> 
>> 
>> 
>> _______________________________________________ Discuss-gnuradio
>> mailing
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> 
_______________________________________________
>> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGoVpAAoJEBQ6EdjyzlHtXpAH/3rMFjvBQxTzxwPuwb7Vfr2s
afzIB7c0SR16EmbQ7XXwGRc413vJrYz9HSP+mHW+d14EId0tJgbD70M0NjA2rIfO
4qJA+OyKxgG/kchpeqH8thHzS5eE8jQxPhAYuE7dgYOK8pD9XW/z6Tnj7xOr7UVP
Xh8nWoM9HXJXq4xagjkXOqsIW8hxAe7JRNuAx7Jrtbe1g1cyjTfROa2KNRyZbxoa
V8V4UeYBt0ab3LGqCwUGB1uMefoGn2Walnb9rcW38jEaLEQ+l33ZgvD3kDte/Jju
78aglgn15tXU0VMbX5ON9ZkLm4lZCx1TQ2Wyf/PxnNhKow9kSfSaoJYnSZ77U0U=
=638A
-----END PGP SIGNATURE-----