Forum: GNU Radio stream_to_vector input data size and lock/unlock

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
992d7640b9396bb5e8baf989281b59c0?d=identicon&s=25 Kieran Brownlees (Guest)
on 2009-03-31 05:52
(Received via mailing list)
Hello all,

I have some interesting behaviour using a stream_to_vector with a large
number of inputs items (12800).

The standard method of top_block.connect(), top_block.start() works fine
but
when I try and perform the same operation after a top block has already
been
started I get a sched error.

Sample test case:

import time
from gnuradio import gr

class top_block (gr.top_block):
    def __init__(self):
        gr.top_block.__init__(self)
        s2v = gr.stream_to_vector(gr.sizeof_gr_complex, 12800)
        ns = gr.null_source(8)
        self.connect(ns, gr.null_sink(8))
        self.start()
        self.lock()
        self.connect(ns, s2v, gr.null_sink(102400))
        self.unlock()

if __name__ == '__main__':
    app = top_block()
    print "End"

If the above python script is run as it is I get this on my 3.1.3
installation:

sdrts@sdrts:~/test$ python s2vtest.py

sched: <gr_block stream_to_vector (1)> is requesting more input data
  than we can provide.
  ninput_items_required = 12800
  max_possible_items_available = 4095
  If this is a filter, consider reducing the number of taps.
End
sdrts@sdrts:~/test$

If however you move the self.start() in the above script below the
second
self.connect and remove the lock() / unlock() then it runs fine (and
works
perfectly). I was just wondering if anyone can explain this behaviour to
me?

Interestingly on my 3.2 install the max_possible_items_available is
8191.

Thank you,
Kieran
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-31 08:04
(Received via mailing list)
On Tue, Mar 31, 2009 at 04:51:45PM +1300, Kieran Brownlees wrote:
>
>         self.lock()
> sdrts@sdrts:~/test$ python s2vtest.py
> self.connect and remove the lock() / unlock() then it runs fine (and works
> perfectly). I was just wondering if anyone can explain this behaviour to me?
>
> Interestingly on my 3.2 install the max_possible_items_available is 8191.
>
> Thank you,
> Kieran

It looks like a bug in the buffer allocator / buffer reuse code that
is executed when reconfiguring a flow graph.  I opened ticket:380 on
this.

Eric
This topic is locked and can not be replied to.