Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

[Marcus D. Leech]

> 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