[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] noutput_items in every block

From: Jeff Long
Subject: Re: [Discuss-gnuradio] noutput_items in every block
Date: Tue, 2 Jan 2018 08:26:40 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

Correction: sync_block guarantees number of inputs (on each port) to be equal to number of outputs. The sync_decimator and sync_interpolator allow number of inputs (on each port) a 1:N or N:1 relationship between input and output. Sorry for the confusion.

On 01/02/2018 08:07 AM, Jeff Long wrote:
Yes, you'll get the same number of samples on both inputs if you derive from sync_block. For example, here is the code from the "add" block:

add_ff_impl::work(int noutput_items,
     gr_vector_const_void_star &input_items,
     gr_vector_void_star &output_items)
   float *out = (float *) output_items[0];
   int noi = d_vlen*noutput_items;

   memcpy(out, input_items[0], noi*sizeof(float));
   for(size_t i = 1; i < input_items.size(); i++)
     volk_32f_x2_add_32f(out, out, (const float*)input_items[i], noi);
   return noutput_items;

For blocks derived from sync_decimator or sync_interpolator, you can also assume that the number of input and output items will be the same (or related).

On 01/02/2018 05:46 AM, Sakthivel Velumani wrote:
Hi Michael,

Thank you very much for the detailed explanation. I have one more query - If a block has two input streams, will the no of items be same in both streams? say for example I build a block that takes I and Q samples as input and the algorithm demands I sample and its corresponding Q sample to work correctly. In this case does the scheduler guarantee that the items in both buffer are of same number and in the same order? or do I have to check that I am processing every Q sample and its corresponding I sample using tags or some other mechanism?


On Mon, Jan 1, 2018 at 5:06 PM, Michael Dickens <address@hidden <mailto:address@hidden>> wrote:

    Hi Sakthivel - Short answers: The value can vary for each call; it
    is determined by the scheduler. I've provided more info below if
    you're curious. Cheers! - MLD

    Details: One way to think of your questions is to imagine the
    finite-length I/O buffers that hold the data between blocks, and
    note that, in general, it is more CPU efficient to process "more"
    data than very small chunks -- typically 1k of data can be handled
    more efficiently than 4 bytes, when you consider the CPU overhead
    required for the scheduler (this is true up to some "large" data
    amount, when processing efficiency peaks and possible even drops
    somewhat off of peak). When the flowgraph starts, these buffers are
    all empty; so the scheduler tries to get blocks to process as much
    input data as possible. Once the flowgraph is running, the buffers
    hold (for all practical purposes) random amounts of data, which
    means that the blocks (in general) will not be able to process the
    amount of data as at startup time. Data will flow roughly in bursts
    from source to sink, but since each block is executing in its own
    thread the end result is data pipelining: "work" for any specific
    block happens when there is simultaneously "enough" input data and
    "enough" output buffer space -- combine the "note" above with this
    concept and you have a rough interpretation of the scheduler
    algorithm. Thus, with data streaming the scheduler has to be able to
    work with dynamic amounts of I/O data / buffer space.

    On Mon, Jan 1, 2018, at 10:30 AM, Sakthivel Velumani wrote:
     > I am new to GNU radio. I have this general doubt that when items
    are streamed from one block to another, how many input_items per
    port (consider a type general block) are passed when the work()
    function of the block is called each time? I guess this is handled
    by the GNU radio's scheduler but would like to know if this is
    constant or it varies for each call?

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]