Re: [Discuss-gnuradio] Large number of overflows...

[Marcus D. Leech]

On 04/22/2010 07:56 PM, Matt Ettus wrote:
>
> I am pretty sure that what you are seeing is that your application is
> not keeping up.  The USRP2 keeps sending data to the computer as fast
> as it generates it.  The ethernet card DMAs it into some buffer in
> memory.  Your app uses it and the driver then frees the buffer.  If at
> some point the driver receives a frame and there is no buffer free for
> it then the packet will be dropped, and you'll see an "S".  S stands
> for sequence number error, which is how the system can tell that there
> is a dropped packet.  It is an overrun occurring in the computer, not
> in the hardware.  The hardware will not overrun.
>
> The best way to test what is happening is to run usrp2_fft.py.  If you
> can run that at the same or higher sample rates than you are using in
> your application, then the driver is not the issue.  My guess is that
> your computer will run without problem at decimation of 6 at worst,
> and more likely all the way down to 4.  Your app is running at a
> decimation of around 12 or 16, so it is your app that can't keep up.
>
>
> Think of it this way -- the fastest Core i7 machines are 3.2 GHz.  For
> a 2 Mbps signal, you only have 1600 cycles per data bit.  Assuming you
> are using at least 2 samples per bit, you only have 800 cycles per
> sample to process them.  This is certainly possible, but you will need
> to optimize your code.
>
> How long are your filters?  Are you using FFT-based filters instead of
> convolution based?  Is too much memory getting copied around?
>
>
For some perspective, based on USRP1 data.

My radio astronomy application runs fairly well at 10.6Msps, on a Core 2
Quad 9XXX (9770?) machine,
  with 8G of memory, and clocked at about 3.2GHz.

My application does a 1Hz-resolution FFT over the data (that's a 10.6M
point FFT!), computes the total power,
  and also does interference notch filtering, using a FFT filter, plus
SETI analysis, pulsar folding, and
  transient detection.  It can keep up, but all 4 cores are pretty busy!

I think Matt's analysis is pretty close to the mark.  One of the
mistakes people make (that I've also made)
  is to specify FIR filters with very-narrow transition widths--that
will cause a very long filter to be created.
  Relaxing the "skirts" on the filter can dramatically reduce CPU
consumption.  I typically use filter "skirts"
  that are roughly 20-25% of the total bandwidth of the filter.  In many
applications, very tight filtering isn't
  a requirement for decent performance of the downstream demodulation,
particularly when link margins
  are reasonably good anyway.

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org