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?
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.