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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio