With these codes, it works find with my own machinie.
Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host
has
i7-3770 and 16 GB RAM.
But it fails on machine that my school gave to me for educational and
research purposes. I can’t tell you the exact spec. of the machine, but
it
apparently has a poor CPU and a lower memory space.
Do these difference on machines’ specs affect on ninput_items? I think
they
have a certain relation to each other… since GNU Radio scheduler
allocates available memory over all blocks…? If so, can it be resolved
if
I manually set a larger memory/buffer size to GNU Radio? (If my memory
is
correct, I remember there’s a configuration file to do it…)
What factor determines input_item size (ninput_items)?
these are two things: the input item size is the size of a single item,
and ninput_items is the amount of items that your (general_)work call
sees.
You are referring to the second thing:
Consider this flow graph:
A -> B -> C
A is the upstream block (e.g. USRP source), B is your block, and C is a
downstream block (e.g. Vector sink).
ninput_items is determined by how many samples are available. Your block
B has no influence on it; whenever the upstream block A finishes doing
its (general_)work, GNU Radio updates the number of items available in
the buffer between A and B. It then asks B whether it wants to work on
this amount of input samples.
I see your forecast method, and it seems to do the right thing: If your
block is in the SYNC state, to output anything, it needs 480 items. If
there’s no 480 input items, GNU Radio won’t call your general_work,
usually. You should try printing ninput_items, to see if that’s correct.
Now, your block has two input streams. If they are somehow related,
timing and buffer sizes might actually lead to a deadlock situation. Can
you give us an overview over the whole flowgraph?
The Gist codes that I’ve referred on the previous post were wrong.
I’ve forgot editting codes related with the second input stream
(input_items[1] and ninput_items[1]) after I removed the second input
stream from a block.
So, ninput = min(ninput_items[0], ninput_items[1]) was doing some
undefined behavior.
And my own machine reads garbage value of ninput_items[1] as 32767,
so the equation is simplified to ninput = ninput_items[0].
But the machine that the school gave me reads garbage value as something
smaller than 240, 480, etc…,
so the to_consume will be zero according to my state machine.
After fixing the codes, I can get the same and correct behaviors and
results on both machines.
In short, it has nothing to do with spec. of a machine.
It’s just all my fault.