Which blocks do you like?

GNU Radio
1

Hi,
for my thesis I’m making “porting” of gnuradio blocks over CUDA…
For the moment,I’ve bring basick blocks,FIR filter,FFT,an FM
receiver(not
so good due to latency) and I’m working with ofdm…I still need to
implement IIR filter

Which other blocks do you think that could be nice(useful,get
performance,…) to bring over CUDA?

Thanks for your opinions,
marco

2

The tone reservation PAPR reduction block used with the DVB-T2
transmitter in gr-dtv may be interesting for you. It uses a ton of
floating point calculations.

Even though it uses Volk kernels extensively, it’s performance is still
lacking. Right now, it’s capable of light PAPR reduction, but for
heavier reduction, it’s takes too much CPU and the transmitter flow goes
non real-time.

The target performance would be a clipping value of 2.57 over 50
iterations, which is what is used in the Ofcom mode 2 profile. Current
performance is a clipping value around 2.9 over 20 iterations (on my
workstation).

Ron

3

Hi Marco,

classically, correlation is an expensive thing, so probably an
implementation of some correlation synchronizer would be interesting!
(also, the raw correlation, but depending on your FIR implementation you
might already have that)
Though this might be nontrivial to come up with an architecture for
that, as it doesn’t really fit the typical CUDA fixed size buffer in -
fixed size buffer out approach.

Best regards,
Marcus

4

On Mon, 2015-05-18 at 12:01 -0400, [email protected]
wrote:

Message: 4
Date: Mon, 18 May 2015 09:52:26 +0200
From: Marcus M?ller [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Which blocks do you like?

[snip]

have the last item greater than the previous…
corr_mag[i+1]). Thanks for spotting that!If you don't mind, I'd like to ask you to fix that line (while(i<noutput_items)->while(i<noutput_items-1)`)and submit a pull
request on github [2] (if possible, base it off the “maint” branch).

Hi Marcus and Marco,

The corr_est block fixes this bug, and a few others, that the original
correlate_and_sync block has. The corr_est block should perform
reliably, whereas the correlate_and_sync block does not, due to bugs.
They are different blocks because the corr_est block has different input
arguments, to handle more general cases.

If you wish to spend time optimizing the performance of a block, I’d
recommend you optimize the corr_est block, not the correlate_and_sync
block. Optimally doing something unreliably is still doing something
unreliably. :slight_smile:

Regards,
Andy

[2]

https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#How-can-I-use-github-to-submit-patchesfeatureschanges

On 05/17/2015 10:58 PM, marco Ribero wrote:

[snip]

5

On Mon, May 18, 2015 at 5:14 PM, Andy W.
[email protected]
wrote:

have the last item greater than the previous…
corr_mag[i+1])`. Thanks for spotting that!If you don’t mind, I’d like to
arguments, to handle more general cases.

If you wish to spend time optimizing the performance of a block, I’d
recommend you optimize the corr_est block, not the correlate_and_sync
block. Optimally doing something unreliably is still doing something
unreliably. :slight_smile:

Regards,
Andy

Plus this block will be removed in 3.8, so it doesn’t have a long life
left.

Tom