Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Thank you all for your comments. Marcus, I'd just like to say that I have been using the packet encoder/decoder for a long time (3-4 years) and could not see any issues that could be attributed to it. Regarding the dropped samples, is it the case that the buffers are continuously grown as the samples accumulate if a block cannot finish processing in time? My apparent dropped samples could have actually been a clock synchronization issue, I can try to reproduce it again to confirm. It is not a terribly important issue though. The FIR filter is too long for 1024 bits Gold codes and can't handle high sample rates. I hope that I will find a solution, currently investigating the core code of FFT filters to determine if a replacement can help. Thanks, Adrian On September 2, 2019 3:30:48 PM UTC, "Müller, Marcus (CEL)" wrote: >I second what Michael wrote, but I'd like to be more general: > >GNU Radio does NOT drop samples, anywhere. SDR or audio or similar >analog/digital hardware might do that when buffers run over. > >There's a long-standing, and seemingly unfixable bug in the >packet_encoder/decoder Python hier blocks that hence have been >deprecated on 3.7 for as long as I remember and have been removed, that >led to samples being dropped. If something like that happens anywhere >but in sampling hardware, there's a fundamental bug and we'd like to >know where exactly! > >Best regards, >Marcus > >On Mon, 2019-09-02 at 13:09 +0300, Adrian Musceac wrote: >> Hi Kevin, >> >> Thanks for the explanation, I think my flawed understading was due to >> the fact of having a file source with a throttle block, and seeing >> samples being dropped from buffers that did not match ASCII bytes >lost >> at the file source but somewhere along the way. Is it correct to >> presume that in this case it is the throttle block that will be >> dropping the samples? >> >> Thanks, >> Adrian >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
I second what Michael wrote, but I'd like to be more general: GNU Radio does NOT drop samples, anywhere. SDR or audio or similar analog/digital hardware might do that when buffers run over. There's a long-standing, and seemingly unfixable bug in the packet_encoder/decoder Python hier blocks that hence have been deprecated on 3.7 for as long as I remember and have been removed, that led to samples being dropped. If something like that happens anywhere but in sampling hardware, there's a fundamental bug and we'd like to know where exactly! Best regards, Marcus On Mon, 2019-09-02 at 13:09 +0300, Adrian Musceac wrote: > Hi Kevin, > > Thanks for the explanation, I think my flawed understading was due to > the fact of having a file source with a throttle block, and seeing > samples being dropped from buffers that did not match ASCII bytes lost > at the file source but somewhere along the way. Is it correct to > presume that in this case it is the throttle block that will be > dropping the samples? > > Thanks, > Adrian > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Adrian - If you use a file source with a throttle, then that section of your flowgraph will not drop samples. Using what Kevin wrote: The file source will "work" as fast as possible, so its output buffer will fill up quickly and any time samples are removed from it & so long as there is file data available the file source will keep the output buffer full -- and hence the throttle's input buffer will basically always be full. The throttle will pass every single sample through eventually, but at an average rate the matches its configuration. When presented with data in this fashion, the throttle will do a very good job of keeping the output sample rate close to that requested. Hence any dropped samples are happening downstream from the throttle. Hope this is useful! - MLD On Mon, Sep 2, 2019 at 6:10 AM Adrian Musceac wrote: > Hi Kevin, > > Thanks for the explanation, I think my flawed understading was due to > the fact of having a file source with a throttle block, and seeing > samples being dropped from buffers that did not match ASCII bytes lost > at the file source but somewhere along the way. Is it correct to > presume that in this case it is the throttle block that will be > dropping the samples? > > Thanks, > Adrian > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Kevin, Thanks for the explanation, I think my flawed understading was due to the fact of having a file source with a throttle block, and seeing samples being dropped from buffers that did not match ASCII bytes lost at the file source but somewhere along the way. Is it correct to presume that in this case it is the throttle block that will be dropping the samples? Thanks, Adrian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
On Sun, Sep 1, 2019 at 3:15 AM Adrian Musceac wrote: > I'd like to know what happens if the block's work function does not finish > within the time allotted to it. > Is part of the input/output buffer dropped, or does it interfere with the > sample rate of the next blocks? > GNU Radio's flow graph has no notion of time or sample rate; it transfers items (samples) from one block to another whenever some are available, and without ever discarding any. If a block in the middle of a chain is slow, then the buffers between blocks upstream of it will be mostly full, and the buffers between blocks downstream of it will be mostly empty. This means that all of the responsibility for dealing with time is on the sink and/or source blocks in the flow graph. If samples are taken too slowly from a source attached to some hardware generating samples at a fixed rate, usually it will discard samples that it cannot fit into its output buffer. Thus, *everything* downstream of the source will see the discard glitch, not just the blocks downstream of the block that is actually the computation bottleneck. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi,
I found this thread very useful, and I have another question regarding the
scheduler internals.
It is my understanding from reading documentation that each block's *work*
or *general_work* function
will be called at the highest sample rate that the block will see, whether
that is on the input or output of the block.
I'd like to know what happens if the block's work function does not finish
within the time allotted to it.
Is part of the input/output buffer dropped, or does it interfere with the
sample rate of the next blocks?
For example, I have a block which filters incoming samples with a variable
tap length matched filter to output the maximum correlation:
https://github.com/kantooon/gr-dsss/blob/master/lib/dsss_decoder_cc_impl.cc
If the filter size is too large, the block will consume too much CPU time
doing the filtering and output some wrong values.
Is this because some output is dropped/truncated, or because it changes the
sample rate of the next blocks?
Thanks,
Adrian
On Sat, Aug 31, 2019 at 4:56 AM Ron Economos wrote:
> If you use set_output_multiple(), you don't have to check the input
> buffer. The block will only execute if there are a multiple of the value
> used in set_output_multiple() items available. For example, if
> set_output_multiple() is set to 256, the block will only execute if
> noutput_items is at least 256, but it could also be 512, 768, 1024, 1280,
> 1536, etc.
>
> Since forecast() sets ninput_items_required to noutput_items, the same
> number of items appears on the input buffer.
>
> Here's a dummy block that just copies input to output to show the
> structure. The loop in general_work() allows for any value of CHUNK_SIZE to
> work properly. With a size of 8900, the loop will typically only execute
> once.
>
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
>
> #include
> #include
> #include "buffer_cc_impl.h"
>
> #define CHUNK_SIZE 8900
>
> namespace gr {
> namespace laura {
>
> buffer_cc::sptr
> buffer_cc::make()
> {
> return gnuradio::get_initial_sptr
> (new buffer_cc_impl());
> }
>
> /*
> * The private constructor
> */
> buffer_cc_impl::buffer_cc_impl()
> : gr::block("buffer_cc",
> gr::io_signature::make(1, 1, sizeof(gr_complex)),
> gr::io_signature::make(1, 1, sizeof(gr_complex)))
> {
> set_output_multiple(CHUNK_SIZE);
> }
>
> /*
> * Our virtual destructor.
> */
> buffer_cc_impl::~buffer_cc_impl()
> {
> }
>
> void
> buffer_cc_impl::forecast (int noutput_items, gr_vector_int
> &ninput_items_required)
> {
> ninput_items_required[0] = noutput_items;
> }
>
> int
> buffer_cc_impl::general_work (int noutput_items,
>gr_vector_int &ninput_items,
>gr_vector_const_void_star &input_items,
>gr_vector_void_star &output_items)
> {
> const gr_complex *in = (const gr_complex *) input_items[0];
> gr_complex *out = (gr_complex *) output_items[0];
>
> printf("noutput_items = %d\n", noutput_items);
> for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
> memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
> in += CHUNK_SIZE;
> out += CHUNK_SIZE;
> }
>
> consume_each (noutput_items);
>
> // Tell runtime system how many output items we produced.
> return noutput_items;
> }
>
> } /* namespace laura */
> } /* namespace gr */
>
> Ron
> On 8/30/19 15:58, Laura Arjona wrote:
>
> Thank you very much Marcus, Michael, Abin, and Ron, really appreciate your
> responses.
> To give some context, I just started designing a prototype reader to
> implement a custom protocol for backscatter neural implants; very excited
> to build my platform with GNU-radio :)
>
> After reading all the information from your responses and links provided,
> I still have a problem with my implementation. According to the buffer
> sizes that you mentioned, I should not have this problem, but
> I think I am missing something. I may need to re-design my
> system/flow-graph, but I would like to get a last advice/help, if possible.
> Thanks in advance!
>
> *I want my block Decoder to consume_each(>8900) but I get overflows "D"
> messages. See details below*
>
> I have 2 general out of tree blocks: Gate and Decoder.
> They both have*:*
> *ninput_items_required[0] = noutput_items;*
> *const gr_complex *in = (const gr_complex *)
> input_items[0];*
>
> * gr_complex *out = (gr_complex *) output_items[0]; *
>
>
> The flow-graph looks like
> *uhd_source -> fir_filter_ccc -> Gate -> Decoder -> other blocks. (Using
> a USRP N210 + SBX) *
> The idea is that I want the block *Decoder* to only process the input
> samples when I have received *k* samples. Let's set k=~8900
> So, at the *Decoder* block general_work(), I set *consume_each(0) *until
> *ninput_items[0]>=k.*
>
> Basica
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
If you use set_output_multiple(), you don't have to check the input
buffer. The block will only execute if there are a multiple of the value
used in set_output_multiple() items available. For example, if
set_output_multiple() is set to 256, the block will only execute if
noutput_items is at least 256, but it could also be 512, 768, 1024,
1280, 1536, etc.
Since forecast() sets ninput_items_required to noutput_items, the same
number of items appears on the input buffer.
Here's a dummy block that just copies input to output to show the
structure. The loop in general_work() allows for any value of CHUNK_SIZE
to work properly. With a size of 8900, the loop will typically only
execute once.
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include "buffer_cc_impl.h"
#define CHUNK_SIZE 8900
namespace gr {
namespace laura {
buffer_cc::sptr
buffer_cc::make()
{
return gnuradio::get_initial_sptr
(new buffer_cc_impl());
}
/*
* The private constructor
*/
buffer_cc_impl::buffer_cc_impl()
: gr::block("buffer_cc",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex)))
{
set_output_multiple(CHUNK_SIZE);
}
/*
* Our virtual destructor.
*/
buffer_cc_impl::~buffer_cc_impl()
{
}
void
buffer_cc_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}
int
buffer_cc_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
printf("noutput_items = %d\n", noutput_items);
for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
in += CHUNK_SIZE;
out += CHUNK_SIZE;
}
consume_each (noutput_items);
// Tell runtime system how many output items we produced.
return noutput_items;
}
} /* namespace laura */
} /* namespace gr */
Ron
On 8/30/19 15:58, Laura Arjona wrote:
Thank you very much Marcus, Michael, Abin, and Ron, really appreciate
your responses.
To give some context, I just started designing a prototype reader to
implement a custom protocol for backscatter neural implants; very
excited to build my platform with GNU-radio :)
After reading all the information from your responses and links
provided, I still have a problem with my implementation. According to
the buffer sizes that you mentioned, I should not have this problem, but
I think I am missing something. I may need to re-design my
system/flow-graph, but I would like to get a last advice/help, if
possible. Thanks in advance!
_I want my block Decoder to /consume_each(>8900/) but I get overflows
"D" messages. See details below_
I have 2 general out of tree blocks: Gate and Decoder.
They both have/:/
/ ninput_items_required[0] = noutput_items;/
/ const gr_complex *in = (const gr_complex *)
input_items[0];/
/ gr_complex *out = (gr_complex *) output_items[0];
/
/
/
/
/
The flow-graph looks like /uhd_source -> /fir_filter_ccc ->/*Gate* ->
*Decode**r* -> other blocks. (Using a USRP N210 + SBX)
/
The idea is that I want the block /Decoder/ to only process the input
samples when I have received /k/ samples. Let's set k=~8900
So, at the /Decoder/ block general_work(), I set /consume_each(0)
/until /ninput_items[0]>=k./
Basically, at the Decoder general_work() I have the following (just a
overview, not pseudo-code):
/ if (ninput_items[0] And one interesting? thing happens. When /ninput_items[0]/ gets close
to /k=8500/ (or higher value), is when I start getting 'D', and after
that /ninput_items[0] = 800/, no matter the value of /k/.
/
/
/
/
Thank you.
Cheers
Laura.
On Fri, Aug 30, 2019 at 7:29 AM Müller, Marcus (CEL) > wrote:
Hi Ron,
just because I think this might be interesting to people dealing with
really high rates:
The maximum size is typically limited by the size of mmap'able memory
that you can allocate; that depends on the circular buffer factory
used:
For the posix shared memory thing, I don't think anything is stopping
you from using "memory space size" order amounts of buffer.
For anonymous file-backed mmap'ed buffers, I'd expect that we haven't
addressed the possibility of using more than 32 bit addresses, so
somewhere around 2 GB you'd find your upper limit.
Best regards,
Marcus
On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote:
> Just to put a number on this question, the DVB-T2 transmitter
uses up to 16 Megabyte
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Thank you very much Marcus, Michael, Abin, and Ron, really appreciate your responses. To give some context, I just started designing a prototype reader to implement a custom protocol for backscatter neural implants; very excited to build my platform with GNU-radio :) After reading all the information from your responses and links provided, I still have a problem with my implementation. According to the buffer sizes that you mentioned, I should not have this problem, but I think I am missing something. I may need to re-design my system/flow-graph, but I would like to get a last advice/help, if possible. Thanks in advance! *I want my block Decoder to consume_each(>8900) but I get overflows "D" messages. See details below* I have 2 general out of tree blocks: Gate and Decoder. They both have*:* *ninput_items_required[0] = noutput_items;* *const gr_complex *in = (const gr_complex *) input_items[0];* * gr_complex *out = (gr_complex *) output_items[0]; * The flow-graph looks like *uhd_source -> fir_filter_ccc -> Gate -> Decoder -> other blocks. (Using a USRP N210 + SBX)* The idea is that I want the block *Decoder* to only process the input samples when I have received *k* samples. Let's set k=~8900 So, at the *Decoder* block general_work(), I set *consume_each(0) *until *ninput_items[0]>=k.* Basically, at the Decoder general_work() I have the following (just a overview, not pseudo-code): * if (ninput_items[0] wrote: > Hi Ron, > > just because I think this might be interesting to people dealing with > really high rates: > The maximum size is typically limited by the size of mmap'able memory > that you can allocate; that depends on the circular buffer factory > used: > For the posix shared memory thing, I don't think anything is stopping > you from using "memory space size" order amounts of buffer. > For anonymous file-backed mmap'ed buffers, I'd expect that we haven't > addressed the possibility of using more than 32 bit addresses, so > somewhere around 2 GB you'd find your upper limit. > > Best regards, > Marcus > > On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote: > > Just to put a number on this question, the DVB-T2 transmitter uses up to > 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum > is, but 16 Megabytes should cover most applications. > > The DVB-T2 blocks use set_output_multiple() in conjunction with > forecast() to allocate these large buffers. > > Ron > > On 8/28/19 11:46, Laura Arjona wrote: > > > Hello GNURadio community, > > > > > > Does anyone know what is the maximum number of input items that an Out > Of Tree block can consume on each input stream? > > > > > > consume_each(consumed) --> what is the maximum value that the variable > consumed can take? > > > > > > Thank you very much. > > > > > > > > > -- > > > Laura Arjona > > > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > > > > > Paul G. Allen School of Computer Science & Engineering > > > 185 E Stevens Way NE > > > University of Washington > > > Seattle, WA 98195-2350 > > > > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- *Laura Arjona * Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Ron, just because I think this might be interesting to people dealing with really high rates: The maximum size is typically limited by the size of mmap'able memory that you can allocate; that depends on the circular buffer factory used: For the posix shared memory thing, I don't think anything is stopping you from using "memory space size" order amounts of buffer. For anonymous file-backed mmap'ed buffers, I'd expect that we haven't addressed the possibility of using more than 32 bit addresses, so somewhere around 2 GB you'd find your upper limit. Best regards, Marcus On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote: > Just to put a number on this question, the DVB-T2 transmitter uses up to 16 > Megabyte buffers between blocks. I'm not sure what the absolute maximum is, > but 16 Megabytes should cover most applications. > The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to > allocate these large buffers. > Ron > On 8/28/19 11:46, Laura Arjona wrote: > > Hello GNURadio community, > > > > Does anyone know what is the maximum number of input items that an Out Of > > Tree block can consume on each input stream? > > > > consume_each(consumed) --> what is the maximum value that the variable > > consumed can take? > > > > Thank you very much. > > > > > > -- > > Laura Arjona > > Washington Research Foundation Innovation Postdoctoral Fellow in > > Neuroengineering > > > > Paul G. Allen School of Computer Science & Engineering > > 185 E Stevens Way NE > > University of Washington > > Seattle, WA 98195-2350 > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Laura - All of what's written already is basically correct. I'll add on
minor tweak: "ninput_items" and "noutput_items", which are 2 of the
arguments to the "work" or "general_work" method, define the maximum number
of input and/or output items available to use or requested to produce; see
the comments in the header for this method: <
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L168
>. Which of these variables is used depends on the actual block type as
already noted: source, sink, sync, tagged_stream, etc ... for example for
a source block -- one that does have inputs -- "ninput_items" is not used;
for a sink block "noutput_items" is not used. For general blocks,
"ninput_items" is as noted in the header: "number of input items available
on each input stream", and "noutput_items" is "number of output items to
write on each output stream" ... but note that both of these are maximums.
The values of these variables generally varies during runtime -- or rather,
it is not guaranteed that they will constant -- so, you can't do something
like "always produce 100 items", because there might not be enough output
buffer space. Hence you have to rely on the values of these variables to
determine how to do "work", and needs to keep track of the number of items
consumed during work (and then consume just that number). Hopefully this
and the other replies provide enough information for you to figure out how
to proceed. Cheers! - MLD
ps> It is -very- cool to have a neuroengineer and anesthesiologist using GR!
On Fri, Aug 30, 2019 at 6:27 AM Albin Stigö wrote:
> Laura et al,
>
> consume_each <= ninput_items.
>
> If you need a larger buffer than you consume you can abuse the
> scheduler slightly by set_relative_rate(1, some_min_input_items), this
> is done in the stream to vector blocks for example. I do this in a
> visualization sink where I need to produce FFTs with a certain
> overlap.
>
> // We need at least this number of points to do our job
> m_input_length = std::max(m_consume_each, m_fft_size);
> // This is probably abusing the scheduler quite a bit
> set_relative_rate(1, m_input_length);
>
> Interesting to see you work in neuroengineering. I'm an
> anesthesiologist and very interested these applications of gnuradio.
>
>
> --Albin
>
> On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller
> wrote:
> >
> > Hi Laura,
> >
> > the buffer sizes are determined at flow graph startup based on the
> > involved block's io signature, output multiples, alignment
> > requirements, minimum and maximum buffer sizes, and the page size
> > (which practically everywhere is 4kB).
> >
> > I think you're expecting the amount of items your block is presented
> > with to be deterministic: it's simply not.
> >
> > It's a thing that depends on the temporal execution of the signal
> > processing flowgraph at run time. Thus, your work (or general_work)
> > must always make sure it works within the boundaries of how many
> > samples are supplied in that specific call, and how much output space
> > is available at that point.
> >
> > I think
> >
> > https://www.gnuradio.org/blog/2017-01-05-buffers/
> >
> > might be of interest to you.
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > > Thank you very much Michael.
> > >
> > > What are the I/O buffer sizes?
> > >
> > > * My block is a general block
> > > * In my forecast: ninput_items_required[0] = noutput_items;
> > > * In the general_work: const gr_complex *in = (const gr_complex *)
> > > input_items[0];
> > > float *out = (float *)
> > > output_items[0];
> > >
> > > /*
> > > * The private constructor
> > > */
> > > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > > output_sizes)
> > > : gr::block("decoder",
> > > gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > > gr::io_signature::makev(2, 2, output_sizes)),
> > > s_rate(sample_rate)
> > > {
> > >
> > >
> > >
> > >
> > > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > > michael.dick...@ettus.com> wrote:
> > > > Hi Laura - In the "work" or "general_work" method, there are
> > > > arguments that contain the information you're looking for. These
> > > > arguments are set depending on what type of block you're creating
> > > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > > what the "forecast()" method returns, and are constrained by the
> > > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > > that the value of the variable "consumed" in your description is
> > > > context dependent. Hope this is useful! - MLD
> > > >
> > > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > > > wrote:
> > > > > Hello GNURadio community,
> > > > >
> > > > > Does anyone know what is the maximum number of input items that
> > > > > an Out Of Tree block can consume on each input stream?
>
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Just to put a number on this question, the DVB-T2 transmitter uses up to 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum is, but 16 Megabytes should cover most applications. The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to allocate these large buffers. Ron On 8/28/19 11:46, Laura Arjona wrote: Hello GNURadio community, Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream? consume_each(consumed) --> what is the maximum value that the variable consumed can take? Thank you very much. -- *Laura Arjona* Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Laura et al,
consume_each <= ninput_items.
If you need a larger buffer than you consume you can abuse the
scheduler slightly by set_relative_rate(1, some_min_input_items), this
is done in the stream to vector blocks for example. I do this in a
visualization sink where I need to produce FFTs with a certain
overlap.
// We need at least this number of points to do our job
m_input_length = std::max(m_consume_each, m_fft_size);
// This is probably abusing the scheduler quite a bit
set_relative_rate(1, m_input_length);
Interesting to see you work in neuroengineering. I'm an
anesthesiologist and very interested these applications of gnuradio.
--Albin
On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller wrote:
>
> Hi Laura,
>
> the buffer sizes are determined at flow graph startup based on the
> involved block's io signature, output multiples, alignment
> requirements, minimum and maximum buffer sizes, and the page size
> (which practically everywhere is 4kB).
>
> I think you're expecting the amount of items your block is presented
> with to be deterministic: it's simply not.
>
> It's a thing that depends on the temporal execution of the signal
> processing flowgraph at run time. Thus, your work (or general_work)
> must always make sure it works within the boundaries of how many
> samples are supplied in that specific call, and how much output space
> is available at that point.
>
> I think
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> might be of interest to you.
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > Thank you very much Michael.
> >
> > What are the I/O buffer sizes?
> >
> > * My block is a general block
> > * In my forecast: ninput_items_required[0] = noutput_items;
> > * In the general_work: const gr_complex *in = (const gr_complex *)
> > input_items[0];
> > float *out = (float *)
> > output_items[0];
> >
> > /*
> > * The private constructor
> > */
> > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > output_sizes)
> > : gr::block("decoder",
> > gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > gr::io_signature::makev(2, 2, output_sizes)),
> > s_rate(sample_rate)
> > {
> >
> >
> >
> >
> > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > michael.dick...@ettus.com> wrote:
> > > Hi Laura - In the "work" or "general_work" method, there are
> > > arguments that contain the information you're looking for. These
> > > arguments are set depending on what type of block you're creating
> > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > what the "forecast()" method returns, and are constrained by the
> > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > that the value of the variable "consumed" in your description is
> > > context dependent. Hope this is useful! - MLD
> > >
> > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > > wrote:
> > > > Hello GNURadio community,
> > > >
> > > > Does anyone know what is the maximum number of input items that
> > > > an Out Of Tree block can consume on each input stream?
> > > >
> > > > consume_each(consumed) --> what is the maximum value that the
> > > > variable consumed can take?
> > > >
> > > > Thank you very much.
> > > >
> > > >
> > > > --
> > > > Laura Arjona
> > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > Neuroengineering
> > > >
> > > > Paul G. Allen School of Computer Science & Engineering
> > > > 185 E Stevens Way NE
> > > > University of Washington
> > > > Seattle, WA 98195-2350
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Michael Dickens, Mac OS X Programmer
> > >
> > > Ettus Research Technical Support
> > >
> > > Email: supp...@ettus.com
> > >
> > > Web: http://www.ettus.com
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Laura,
the buffer sizes are determined at flow graph startup based on the
involved block's io signature, output multiples, alignment
requirements, minimum and maximum buffer sizes, and the page size
(which practically everywhere is 4kB).
I think you're expecting the amount of items your block is presented
with to be deterministic: it's simply not.
It's a thing that depends on the temporal execution of the signal
processing flowgraph at run time. Thus, your work (or general_work)
must always make sure it works within the boundaries of how many
samples are supplied in that specific call, and how much output space
is available at that point.
I think
https://www.gnuradio.org/blog/2017-01-05-buffers/
might be of interest to you.
Best regards,
Marcus
On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> Thank you very much Michael.
>
> What are the I/O buffer sizes?
>
> * My block is a general block
> * In my forecast: ninput_items_required[0] = noutput_items;
> * In the general_work: const gr_complex *in = (const gr_complex *)
> input_items[0];
> float *out = (float *)
> output_items[0];
>
> /*
> * The private constructor
> */
> decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> output_sizes)
> : gr::block("decoder",
> gr::io_signature::make(1, 1, sizeof(gr_complex)),
> gr::io_signature::makev(2, 2, output_sizes)),
> s_rate(sample_rate)
> {
>
>
>
>
> On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> michael.dick...@ettus.com> wrote:
> > Hi Laura - In the "work" or "general_work" method, there are
> > arguments that contain the information you're looking for. These
> > arguments are set depending on what type of block you're creating
> > (source, sink, sync, tagged_stream, whatever), are influenced by
> > what the "forecast()" method returns, and are constrained by the
> > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > that the value of the variable "consumed" in your description is
> > context dependent. Hope this is useful! - MLD
> >
> > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > wrote:
> > > Hello GNURadio community,
> > >
> > > Does anyone know what is the maximum number of input items that
> > > an Out Of Tree block can consume on each input stream?
> > >
> > > consume_each(consumed) --> what is the maximum value that the
> > > variable consumed can take?
> > >
> > > Thank you very much.
> > >
> > >
> > > --
> > > Laura Arjona
> > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > Neuroengineering
> > >
> > > Paul G. Allen School of Computer Science & Engineering
> > > 185 E Stevens Way NE
> > > University of Washington
> > > Seattle, WA 98195-2350
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > --
> > Michael Dickens, Mac OS X Programmer
> >
> > Ettus Research Technical Support
> >
> > Email: supp...@ettus.com
> >
> > Web: http://www.ettus.com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Thank you very much Michael.
What are the I/O buffer sizes?
* My block is a general block
* In my forecast:* ninput_items_required[0] = noutput_items;*
* In the general_work: const gr_complex *in = (const gr_complex *)
input_items[0];
*float** *out = (float *)
output_items[0]; *
/*
* The private constructor */
decoder_impl::frame_decoder_impl(int sample_rate,std::vector
output_sizes) : gr::block("decoder",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::makev(2, 2, output_sizes)),
s_rate(sample_rate){
On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens
wrote:
> Hi Laura - In the "work" or "general_work" method, there are arguments
> that contain the information you're looking for. These arguments are set
> depending on what type of block you're creating (source, sink, sync,
> tagged_stream, whatever), are influenced by what the "forecast()" method
> returns, and are constrained by the I/O buffer sizes. Sorry to be a little
> vague, but the answer is that the value of the variable "consumed" in your
> description is context dependent. Hope this is useful! - MLD
>
> On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona wrote:
>
>> Hello GNURadio community,
>>
>> Does anyone know what is the maximum number of input items that an Out Of
>> Tree block can consume on each input stream?
>>
>> consume_each(consumed) --> what is the maximum value that the variable
>> consumed can take?
>>
>> Thank you very much.
>>
>>
>> --
>> *Laura Arjona *
>> Washington Research Foundation Innovation Postdoctoral Fellow in
>> Neuroengineering
>>
>> *Paul G. Allen School of Computer Science & Engineering*
>> 185 E Stevens Way NE
>> University of Washington
>> Seattle, WA 98195-2350
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>
--
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering
*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Laura - In the "work" or "general_work" method, there are arguments that contain the information you're looking for. These arguments are set depending on what type of block you're creating (source, sink, sync, tagged_stream, whatever), are influenced by what the "forecast()" method returns, and are constrained by the I/O buffer sizes. Sorry to be a little vague, but the answer is that the value of the variable "consumed" in your description is context dependent. Hope this is useful! - MLD On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona wrote: > Hello GNURadio community, > > Does anyone know what is the maximum number of input items that an Out Of > Tree block can consume on each input stream? > > consume_each(consumed) --> what is the maximum value that the variable > consumed can take? > > Thank you very much. > > > -- > *Laura Arjona * > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > *Paul G. Allen School of Computer Science & Engineering* > 185 E Stevens Way NE > University of Washington > Seattle, WA 98195-2350 > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Maximum input items consumed on each input stream
Hello GNURadio community, Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream? consume_each(consumed) --> what is the maximum value that the variable consumed can take? Thank you very much. -- *Laura Arjona * Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
