# What factor determines input\_item size (ninput\_items)? **URL:** \ **Category:** GNU Radio\ **Created:** [August 28, 2015, 7:01pm UTC](https://www.ruby-forum.com/t/what-factor-determines-input-item-size-ninput-items/243174 "2015-08-28T19:01:15Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [August 28, 2015, 7:01pm UTC](https://www.ruby-forum.com/t/what-factor-determines-input-item-size-ninput-items/243174/1 "2015-08-28T19:01:15Z")
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](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](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. ---
**Author:** ![Jeon](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e8c25b/32.png) [@Jeon](https://www.ruby-forum.com/u/Jeon)\ **Post date:** [August 28, 2015, 7:35pm UTC](https://www.ruby-forum.com/t/what-factor-determines-input-item-size-ninput-items/243174/2 "2015-08-28T19:35:08Z")
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 ---
**Author:** ![Jeon](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e8c25b/32.png) [@Jeon](https://www.ruby-forum.com/u/Jeon)\ **Post date:** [August 29, 2015, 3:42pm UTC](https://www.ruby-forum.com/t/what-factor-determines-input-item-size-ninput-items/243174/3 "2015-08-29T15:42:00Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):