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....