-----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 <mar...@hostalia.de> > 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 <t...@trondeau.com> >> wrote: >> >>> On Thu, Mar 6, 2014 at 2:12 AM, Activecat <active...@gmail.com> >>> 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 >> listDiscuss-gnuradio@gnu.orghttps://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 > -----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----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
