Agree the throttle it not the best solution. David - what is your
source, and what problem are those 1000's of vectors causing at startup?
- Jeff
On 10/14/2014 06:08 PM, Matt Ettus wrote:
>
> Jeff,
>
> If there is a hardware device like a USRP in the chain, then you should
> not use a throttle block. What you are seeing is the initial startup
> burst. When everything starts up, all the buffers are empty, and GNU
> Radio will generate data until something backs up. Once they fill up,
> you are seeing the rate settle down. This is all normal.
>
> If you really need to rate limit what gets requested of the database
> during the initial transient (which I don't recommend), you should do
> that within your source block.
>
> Matt
>
>
> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long <address@hidden
> <
mailto:address@hidden>> wrote:
>
> Should have mentioned ... set the throttle rate just slightly higher
> than what the chain would consume at steady state when all the
> buffers are filled and the USRP is transmitting. How well this works
> depends on what the rest of the chain looks like.
>
> - Jeff
>
>
> On 10/14/2014 05:52 PM, Jeff Long wrote:
>
> Use a throttle block immediately after your source block,
> setting the
> vector size to match your source.
>
> - Jeff
>
> On 10/14/2014 04:34 PM, David Halls wrote:
>
> Dear All,
>
> I am wondering how to add some flow control to a source
> block, so that
> it doesn’t fire out items so quickly.
>
> Later stages of my flow graph are slowed by various bits of
> processing
> and combining, before transmission via USRP, with bursts being
> transmitted every few seconds.
>
> What happens is that the block fires out 1,000s of vectors,
> and then
> seems to slow down and settle into sync with the rest of the
> flow graph
> after a few seconds. As my source block is reading in from a
> Database, I
> want to slow this initial rate significantly.
>
> The block outputs vectors of bytes (v_len=144). Any ideas?
>
> Regards,
>
> David
>
> ------------------------------__------------------------------__---
>
> David Halls Ph.D.
>
> Research Engineer
>
> Toshiba Research Europe Limited
>
> 32 Queen Square, Bristol, BS1 4ND, UK
>
> Tel: +44 (0) 117 906 0790
> <tel:%2B44%20%280%29%20117%20906%200790>
>
>
> ------------------------------__------------------------------__------------
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be
> read, copied
> and used only by the intended recipient. If you are not the
> intended
> recipient, please destroy this message, delete any copies
> held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park,
> Milton Road,
> Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trl
> <
http://www.toshiba.eu/research/trl>
>
>
>
> ------------------------------__------------------------------__------------
> This email has been scanned for email related threats and
> delivered
> safely by Mimecast.
> For more information please visit
http://www.mimecast.com
> ------------------------------__------------------------------__------------
>
>
> _________________________________________________
> Discuss-gnuradio mailing list
> address@hidden <
mailto:address@hidden>
>
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
> <
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>
>
> _________________________________________________
> Discuss-gnuradio mailing list
> address@hidden <
mailto:address@hidden>
>
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
> <
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio