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

[Josh Blum]

> 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. :-)

> 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.

Also, you may consider timing a particular operation as a performance
metric, rather than counting the number of demodulated packets.

> 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.

> 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/

> 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