# Which blocks do you like? **URL:** \ **Category:** GNU Radio\ **Created:** [May 16, 2015, 12:52am UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968 "2015-05-16T00:52:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [May 16, 2015, 12:52am UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968/1 "2015-05-16T00:52:10Z")
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 ---
**Author:** ![marco\_Ribero](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@marco\_Ribero](https://www.ruby-forum.com/u/marco_Ribero)\ **Post date:** [May 16, 2015, 1:39am UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968/2 "2015-05-16T01:39:29Z")
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 ---
**Author:** ![marco\_Ribero](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@marco\_Ribero](https://www.ruby-forum.com/u/marco_Ribero)\ **Post date:** [May 16, 2015, 3:40pm UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968/3 "2015-05-16T15:40:41Z")
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 ---
**Author:** ![marco\_Ribero](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@marco\_Ribero](https://www.ruby-forum.com/u/marco_Ribero)\ **Post date:** [May 19, 2015, 4:18pm UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968/4 "2015-05-19T16:18:11Z")
On Mon, 2015-05-18 at 12:01 -0400, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Message: 4 > Date: Mon, 18 May 2015 09:52:26 +0200 > From: Marcus M?ller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > 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\`while(i\ > 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. 🙂 Regards, Andy > [2] [https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#How-can-I-use-github-to-submit-patchesfeatureschanges](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] ---
**Author:** ![marco\_Ribero](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@marco\_Ribero](https://www.ruby-forum.com/u/marco_Ribero)\ **Post date:** [May 19, 2015, 4:59pm UTC](https://www.ruby-forum.com/t/which-blocks-do-you-like/241968/5 "2015-05-19T16:59:04Z")
On Mon, May 18, 2015 at 5:14 PM, Andy W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 🙂 > > Regards, > Andy Plus this block will be removed in 3.8, so it doesn’t have a long life left. Tom