Re: [Discuss-gnuradio] What factor determines input_item size (ninput_items)?

[Jeon]

Dear, Marcus

Sorry for telling it. It is just my mistake.

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.

Regards,

Jeon.

2015-08-29 2:34 GMT+09:00 Marcus Müller <address@hidden>:

Hi Jeon,

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?

Best regards,
Marcus

On 28.08.2015 19:00, Jeon wrote:

I am testing my OOT module in various condition of different machines.

A certain block implementing a state machine requires a certain number of items or more.

Thus, I've stated it in forecast():
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp

In general work(), the block determines how many items it should be consume:
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp

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

Regards,

Jeon.

_______________________________________________
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