discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] How to specify maximum size of input buffers on b


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] How to specify maximum size of input buffers on blocks
Date: Fri, 26 Feb 2016 10:52:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

Hi Gonzalo,

these are the mails I like most :)
On 25.02.2016 01:11, Gonzalo Arcos wrote:
Suppose i have a file source, connected to 2 blocks, one, lets call it Block A, does always return instantly after general work is called, in other words, it will never consume an input item. The other one, say its block B, is the identity block, it consumes and output exactly what it receives as input.


The output of the first block is a null sink (since i know it will not produce any output), and the output of the second block is a file sink.
So:
              /->A->Null Sink
File Source -|
              \->B->File Sink

What i am experiencing at running this flowgraph, is that block B will work for the very first seconds (or centiseconds), and will eventually block. This is because A has never consumed an input item, so i guess A's input buffer is full. Because of this, the file sink cannot push any more items further into the flowgraph, resulting in B not having any new input items to process.
Exactly!
So the mechanism below is: the output buffer of File Source is the input buffer of A and the input buffer of B. No memory duplication here.
File Source has a buffer writer with a write pointer, and A and B have their own read pointers pointing into that buffer.
When File Source produces N items, the write pointer advances by N. Similarly, when A consumes M items, A's read pointer advances by M.
When calling (general_)work, the input_items buffer(s) is (are) really just a pointer (start_of_buffer + read pointer). Equivalently, the output_items buffer(s) is (are) really just pointing to the write pointer.

File Source is only allowed to produce so many items that the write pointer doesn't advance beyond the minimum read pointer, because in that case, it would overwrite samples that a downstream block hasn't consumed.

So, my question is, how big is the input buffer of A?
Depends. Typically (64bit Linux), 8192 complex items get allocated, but that really depends on various factors.
Is that customizable?
Yes! For example, as you noticed, in the GRC, open the "advanced" tab in a block property; there's a "Min Output Buffer" and a "Max Output buffer field". There's corresponding methods to set these sizes in the gr::block class[1].
Can i increase the size, so the flowgraph wont block at the first seconds, but at a minute, for example?
Yes; but that might, depending on the rate in which the file source produces samples, be *a whole lot* of memory!
I recommend not doing that, but instead:
  1. Make A consume the items it has read (because, as far as I can tell, you don't actually need them, afterwards, do you?)
  2. implement your "end the running of this flowgraph after X samples" by adding a "head" block, which has the functionality to simply consume all N input samples, copy them from its input to its output buffer, and then consume(N). If sum(N) == X, it says it's done and thus leads to the flowgraph be shut down
Can i specify a policy for a block that if it reaches X amount of samples in its input buffer to drop some of the input?
You could just write a block that does that for you.

Ive seen that each block has minimum output buffer and maximum output buffer in grc. However, i do not see any option regarding its INPUT buffer.
Because there's no such thing as a dedicated input buffer :) because every input buffer is in fact the output buffer of the upstream block.

Another thing i thought is that A's input buffer is the file source output buffer, therefore by adjusting the output buffer of the file source, i am adjusting A's (and B's) input buffer. However, the output buffer of the file source is 0, so i guess its "infinite".
No, 0 just instructs GRC to not write a line containing a "set_min_output_buffer" call[2], so GNU Radio uses the default.

Best regards,
Marcus

[1] https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a9d10e3f6747f91b215abe81b60a003d5
[2] https://github.com/gnuradio/gnuradio/blob/master/grc/python/flow_graph.tmpl#L230


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

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