> On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote:
>> 5) How well is GnuRadio suited for real-time operation?
>
> In a general sense, yes, GNU Radio is well suited for real-time signal processing of data streams. That said: "Real time" is only meaningful knowing the performance criteria. What sort of performance do you require processing for?
Real-time is not about performance, but about predictability ;)
I have to be sure that my flowgraph always executes before the
deadline is hit. So everything that introduces jitter is a no-no.
>> 5.1) Specifically - is memory allocated from heap with malloc() or it
>> supports non-blocking memory pools?
>
> IIRC (Tom? Eric?): GNU Radio uses the standard C++ "new" command for most memory allocations -- and thus it is memory from the heap. One can always overload this method globally or locally if required, to provide memory from pools or other means.
Is this "new" called during the flowgraph execution loop? It's too
bad, if it is. Standard memory allocation schemes introduce random
delays in a thread execution. And implementation of a lock-free memory
allocator is a complex task. We used memory pools instead, but this
requires special care - you can't replace a "new" with memory pool
get() with a regexp.
>> 5.2) Can the whole flowgraph be executed from a single thread to
>> minimize cross-thread communication overhead (and jitter)?
>
> Yes. Your choices are a single thread for all or 1 thread per block. - MLD
Great.
--
Regards,
Alexander Chemeris.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment