On Sat, May 28, 2011 at 19:38, Michael Dickens <m...@alum.mit.edu> wrote: > 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