[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Re: FM data available
From: |
Stephane Fillod |
Subject: |
Re: [Discuss-gnuradio] Re: FM data available |
Date: |
Thu, 20 Feb 2003 00:53:41 +0100 |
User-agent: |
Mutt/1.4i |
On Wed, Feb 19, 2003 at 10:29:27AM -0800, Eric Blossom wrote:
> > Sadly enough, my Duron 1GHz is a bit slow too on data crunching, especially
> > using generic code for FIR filters. So I wrote fir_SCC optimization (for
> > GrFreqXlatingFIRfilter) using 3DNow!Ext, and it improves a bit:
> >
> > (address@hidden:examples)$ ./benchmark_dotprod_SCC
> > generic: taps: 256 input: 4e+07 cpu: 107.360 taps/sec: 9.538e+07
> > 3DNow!Ext: taps: 256 input: 4e+07 cpu: 29.710 taps/sec: 3.447e+08
>
> Excellent!
Some new numbers (SSE still WIP):
(address@hidden:examples)$ ./benchmark_dotprod_SCC
generic: taps: 256 input: 4e+07 cpu: 107.360 taps/sec: 9.538e+07
3DNow!Ext: taps: 256 input: 4e+07 cpu: 28.640 taps/sec: 3.575e+08
3DNow!: taps: 256 input: 4e+07 cpu: 50.920 taps/sec: 2.011e+08
Remark: SCC is half the speed of FFF dotprod because Complex taps are involved.
> > I'll submit a patch when I have regular 3DNow! and SSE done.
> > For GrRealFIRfilter, what to you think is best? optimize fir_FSF or use
> > fir_FFF with convert_FS ?
>
> I'll get back to you later.
The best solution, which I implemented already, is to not use conver_FS,
but make use of float_dotprod_xxx, and cast the result to a short.
Unfortunately, the GrRealFIRfilter speed boost (even with 529 coeffs)
is not as noticeable as GrFreqXlatingFIRfilter (which runs at high
sampling rate).
BTW, is there a mean to gather some stats about the various sig
process figures in the chain? This would to know where most of the CPU cycles
are spent.
> > I have another request for data file.
> > Is it possible for you to provide me a data file (16-bit, 20MS/s,
> > size<100Mo),
> > containing Narrow FM, USB, and AM. Something like a Ham portion plus
> > air-band for the AM would be fine. In need to have data for *each* of
> > these modes to be able to test all the demodulators.
>
> I don't have this data. Perhaps someone else can come up with it.
Wouldn't it be possible for anyone with a microtune board to tune to 144MHz
and then sweep the ham band? Some samples around 125MHz would be neat too.
Cheers
Stephane