On Sat, May 28, 2011 at 19:52, Marcus D. Leech <[email protected]> wrote: >> Problem here is that FIFO's are not very well suited for real-time >> operation, IIRC. Have you tried a shared memory and shared signals >> across applications? >> > It depends on what you mean by "real time". Certainly FIFO I/O will be > slower than > intra-flowgraph ring buffers, but not so horribly sluggish and latency > prone that they > can't be used for a large class of real-time applications.
I mean "Soft Real-Time": http://en.wikipedia.org/wiki/Real-time_computing#Hard.2C_firm.2C_and_soft_real-time So, I actually do care about two parameters: 1) "Real-timeness" - i.e. whether using of this primitive can introduce unexpected delays into execution. 2) Latency and throughput - if "real-timeness" requirement is met, then I want to know how well performance of the primitive is. > I use them extensively in a radio astronomy application, and they don't seem > to add any > noticable latency above the already-not-spectacular latency within Gnu > Radio. Is there information about what is the biggest latency-injector in GnuRadio? >> Good idea. With only one problem - XML is a bit of overhead for >> real-time application messaging :) > > Are you concerned about parsing overhead? And what do you mean by "real > time"?? > Are you concerned about reacting to stimuli on microsecond timescales? In > which case, > deep thought would certainly be required about the entire architecture, and > not just > the protocol "syntax". That's what I try to do right now - evaluate whether GnuRadio can perform well enough in general :) I probably spent too much time developing VoIP media processing where you can hear every "non-realtimness" with your ears. But RF processing should be no less real-time, imho. -- Regards, Alexander Chemeris. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
