|
From: | Activecat |
Subject: | Re: [Discuss-gnuradio] self.set_min_noutput_items() is not a valid python command in gnuradio ? |
Date: | Sat, 8 Mar 2014 11:50:06 +0800 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Activecat,
If set_output_multiple just sets the gr::block's field that
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).
>
gr::block::output_multiple() returns, then yes, it works for the next
iteration.
Hm, I'd call this a bug, iff (!) your forecast does everything right.
>
> 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.
>
Can you confirm?
> Regards, Activecat
>
Greetings,
Marcus
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> 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
>>-----BEGIN PGP SIGNATURE-----
>>
>>
>>
>>
_______________________________________________
>> 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
>
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-----
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |