[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Try to improve E100's performance at high sample
From: |
ziyang |
Subject: |
Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate |
Date: |
Mon, 16 Jan 2012 18:51:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110419 Thunderbird/3.1.9 |
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
- [Discuss-gnuradio] Try to improve E100's performance at high sample rate, ziyang, 2012/01/13
- Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate, ziyang, 2012/01/19
- Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate, Nick Foster, 2012/01/19
- Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate, ziyang, 2012/01/19
- Re: [Discuss-gnuradio] Try to improve E100's performance at high sample rate, ziyang, 2012/01/24