[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Date: Sat, 28 May 2011 12:24:53 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]