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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
