Is there information about what is the biggest latency-injector in GnuRadio?
Nearly all of the basic computational blocks are as blazing-fast as they
can be on a general-purpose
CPU. The biggest latency injector is the scheduler in general, and
the buffer management part of
that scheduler in particular. The Gnu Radio architecture is
optimized for throughput, not latency, which
means *BIG* ring-buffers between blocks, and a complicated mechanism
for calculating the "shape" of
those ring buffers.
Scheduling across multiple threads is *great* for throughput, to be
sure, but it complicates optimization in
other directions. This is not an easy problem to solve.
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.
It depends very much on the type of RF processing you're doing. Gnu
Radio is used for a *large* number of different applications--some of
those applications are a more-awkward fit, and some fit really well.
RF signal processing doesn't have a single set of universal
constraints that
everyone can agree on are "vital". Even among different types of
telecom applications, there isn't general agreement--some have
quite-sloppy requirements for latency, while others have very tight
requirements for latency.
For my use of Gnu Radio, I care very much about overall throughput-type
performance, and reliability of the data. I dont' have a "stimulus
response" type of model that needs to respond on timescales of a few
sample times. But others have much-tighter requirements. I don't
need to know in real-time, for example, that the ionosphere has
changed reflectivity by 1%--I'm perfectly happy to find out about that
up to several seconds after it's happened :-) In my science
application that does active RFI-excision, it needs to respond on very lazy
timescales, since one spends perhaps several days building up an "RFI
map" (and the corresponding notch filter coefficients) before
commencing "real science".
But there have certainly been plenty of other folks on this list trying
to get a good feel for the "shape" of the real-timeness of Gnu Radio,
and whether it would be suitable "out of the box" for their
application. All I can suggest is to try some experiments on various host
hardware, with the latest code, and see where it takes you.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
