Double buffering with new thread-per-block scheduler

Hi,

What is the best way to implement double buffering with the new
scheduler? I’m hoping to solve some bursty I/O with sufficient average
bandwidth.

I am thinking of creating a enqueue sink block, and a dequeue source
block. Do you think this will work with the new scheduler? Is it a
problem if the resulting graph has two disjoint parts?

juha

Responding to my own mail. It seems that you cannot have two disjoint
parts within a graph.

For now I solved the problem by increasing nblocks to an insanely large
number.

juha

On Thu, Sep 04, 2008 at 12:04:23AM +0300, Juha V. wrote:

juha
I’m not exactly sure what you’re asking.

All block-to-block connections are double buffered when running with
the thread-per-block scheduler.

How much buffering do you think you need?

There’s no problem with the graph having N disjoint parts.

Eric

On Thu, Sep 04, 2008 at 01:12:26AM +0300, Juha V. wrote:

Responding to my own mail. It seems that you cannot have two disjoint
parts within a graph.

This is incorrect.

See for example the “single argument version of connect” such as used
in gnuradio-examples/python/digital/tunnel.py and documented in
gr_hier_block2.h

class my_top_block(gr.top_block):

def __init__(self, mod_class, demod_class,
             rx_callback, options):

    gr.top_block.__init__(self)
    self.txpath = transmit_path(mod_class, options)
    self.rxpath = receive_path(demod_class, rx_callback, options)

self.connect(self.txpath);
self.connect(self.rxpath);

For now I solved the problem by increasing nblocks to an insanely large number.

You could create a block that’s sole purpose was to serve as your
large buffer. It could have an arbitrarily large internal buffer (10M
samples?). It would derive from gr_block.

By default the buffer size between each block is on the order of 64KB.

Eric

On Thu, Sep 4, 2008 at 03:36, Eric B. [email protected] wrote:

On Thu, Sep 04, 2008 at 01:12:26AM +0300, Juha V. wrote:

Responding to my own mail. It seems that you cannot have two disjoint
parts within a graph.

This is incorrect.

Good.

See for example the “single argument version of connect” such as used
in gnuradio-examples/python/digital/tunnel.py and documented in
gr_hier_block2.h

Thank you for this information, this helps me forward.

You could create a block that’s sole purpose was to serve as your
large buffer. It could have an arbitrarily large internal buffer (10M
samples?). It would derive from gr_block.

This was my idea, but until now, I couldn’t figure out how to do it in
practice.

By default the buffer size between each block is on the order of 64KB.

OK. Good to know.

And thank you for the new scheduler.

juha