>> 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment