|
From: | Marcus D. Leech |
Subject: | Re: [Discuss-gnuradio] GRC flow graph taking longer than I think it should |
Date: | Mon, 06 Mar 2017 15:45:59 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 03/06/2017 03:18 PM, Thomas Wright wrote:
Thanks for the info. Would writing the same program using c++ gnuradio apis give better performance? is there anything else we can to to significantly improve performance aside from not using gnuradio? Thanks again.You can modify latency by changing buffer sizes, for example, in the "options" block you can specify the max_items.-Scott
But buffer management, which trades-off *throughput* vs *latency is a tricky subject. Folks other than me probably have better insights into the Gnu Radio scheduler to help make these trade-offs. By default, Gnu Radio is optimized for *throughput*, which means that latency can take a hit--ESPECIALLY at lower sample rates. Even a "modest" 16K-item buffer will incur 80 or so msec of latency at
195Ksps.Also, you're using old-style message queues, which are, I believe deprecated.
It would be better to learn how to write your own OOT processing block, than to stuff raw data into a (obsolete) message queue, and have
"ordinary" python code process it.
[Prev in Thread] | Current Thread | [Next in Thread] |