Hi Jason - This behavior is normal. If you're curious, read through the code in gnuradio-runtime/lib/block_executor.cc, specifically here: < https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L395 >. Note the comments: "not enough input on input[i]" and "if we can, try reducing the size of our output request" coupled with dividing the number of output items to test for (in ::forecast). The implication is that some upstream block isn't providing data as fast as this block is consuming it. So it's not the downstream null sink that's causing this behavior, it's whatever is upstream. Hope this helps! - MLD
On Mon, Nov 6, 2017, at 12:46 PM, Jason Matusiak wrote: > I am having a problem understanding something simple in my general_work > function. > > I have a forecast function, but I seem to get different sizes for > ninput_items/noutput_items in general_work. What I currently do is find > the minimum of the two values and work off of that: int min_items = > (ninput_items[0] < noutput_items) ? ninput_items[0] : noutput_items;. > > In my mind that makes sense, but if I print out the values of > ninput_items/noutput_items, I see something I think is odd. Over and > over it looks like this (where this is ninput_items/noutput_items= > min(ninput_items,noutput_items): > 2044/1024=1024 > 1020/512=512 > 508/256=256 > 252/128=128 > 124/64=64 > 60/32=32 > 28/16=16 > 12/8=8 > 4/4=4 > 2044/1024=1024 > 1020/512=512 > 508/256=256 > 252/128=128 > 124/64=64 > 60/32=32 > 28/16=16 > 12/8=8 > 4/4=4 > > Is this divide-by-two on the output port action what is supposed to > happen? I don't understand why it keeps dropping and then jumps up in > size again. I am driving a null sink, so it should be able to keep up > no problem.... _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
