On 04/22/2010 04:38 PM, Ian Holland wrote:
Hi Matt
Myself and a colleague have created a C++ equivalent for the same
flowgraph, with realtime scheduling enabled. We still have overruns for
data rates above 2 Mbps, even on a Core i7 machine. We will try and make
a multi-threaded version to hopefully resolve this, since our version is
only single-threaded at this stage.
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?
In regards to using GRC to create the flowgraph, how can I check if
realtime scheduling is enabled, and/or enable realtime scheduling?
It is the last option in the "Options" top block.
Matt
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
