Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate

[ziyang]

On 01/13/2012 09:30 PM, Josh Blum wrote:
> > To reduce the computation load of the processor, I tried two methods:
> > 1) modify the gr.quadrature_demod_cf block, replace some multiplication
> > operations with volk-based operations (gr.multiply and gr.multiply_const
> > modules in gr_blocks);
> I like it. Make sure to contribute patches like that back. :-)
Actually, what I did was writing a new quadrature_demod block without 
the multiplication and delay operations, and connect extra gr.multiply 
and gr.delay blocks instead in the flow graph. Because my understanding 
is that the volk functions take a vector (multiple values) as input, and 
I didn't figure out a way to do the single-item-operation in the volk style.

> > 2) use complex_int16 type instead of complex_float32 at uhd interfaces
> > and modulation / demodulation blocks.
> >
> > But I got unexpected results after the changes. If I adopt method 1),
> > the amount of correctly demodulated data is roughly the same as when
> > using the original demodulation block. And for method 2), the result is
> > even worse - less data is correctly demodulated.
> I wouldnt expect it to be worse in general. How did you implement it?
> Did you combine the float to short conversion into the processing of
> another block? Or did you add an extra block of conversion from float to
> short, because the extra conversion would definitely make things worse.
I wrote a new pair of modulation / demodulation blocks with the same 
processing steps but with short types (in the demodulation block, only 
one step (multiplication) is done with short inputs, then convert to 
float types before using the gr_fast_atan2f function). As the way in 
method 1), I added an extra block in python to do the delay work. So 
will it make things worse if a processing step is taken out of one block 
and done in a separate block?

> Also, you may consider timing a particular operation as a performance
> metric, rather than counting the number of demodulated packets.
I was wondering if there are examples from which I can learn how to do 
this?
> > Could someone please tell me if I did something wrong, or there are
> > other solutions to this overflow-at-high-sample-rate problem?
> >
> > On e100, I burned the latest console file system, use
> > UHD_003.004.000-6795022, and Josh's next branch of GNU radio,
> > uhd setup: center frequency 2.416 GHz, sample rate 4M.
> BTW, I just updated my next branch, in which I pulled into it the
> volk-ified adder, multipliers. So if any of the code you are using,
> includes a gr.add, add const, mult, etc for floating point or float
> complex; you will get the benefit without any code change.
That's great, thanks!
> > BTW, it took almost twice the amount of time to build both uhd and GNU
> > radio after burning the latest console file system, and the
> > initialization process of uhd (when device information is printed out)
> Where did you get the rootfs? When I hear "console" image, I think you
> might be using something very very old. Perhaps you just downgraded by
> accident. You can find the latest stuff here:
>
> http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-create-re-create-E1xx-SD-Card-Images
>
> http://files.ettus.com/e1xx_images/e1xx-002/
I get the rootfs from here:

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Images

I changed the u-boot back to an updated version as Philip said, now the 
initialization time of uhd is normal.

> > took a lot longer time than before as well. But what I concerned more is
> > that much fewer packets could be received, compared with another e100
> > which has the same flow graph setup but installed previous versions of
> > tools: file system, UHD_003.004.000-1a25e48, GNU radio 3.5.0. Could it
> Can you isolate some of the changes? Perhaps keep the console image
> constant, or version or maybe uhd; basically to see in which package,
> uhd, gnuradio, rootfs, gcc there was this performance regression?
>
> I cant recall something specific in gnuradio or uhd that would have
> changed performance. There is honestly not significant e100 changes
> between 1a25e48 and current master.
>
> -Josh
Actually, before I re-burn the rootfs and build the latest uhd, 
gnuradio, the performance of packet demodulation on this e100 was worse 
than on the other one: with the same flow graph and the same uhd 
configurations, less packets could be received on this e100. So I got 
confused and started to wonder if there were hardware problems. Could 
you give me some advices about how to narrow down the problem? Thanks.


Best Regards,

Terry
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio