On Wed, Apr 22, 2009 at 1:48 PM, Juha Vierinen <jvier...@gmail.com> wrote:
> I have been trying to get 25 MHz to disk with USRP2. I am using the > C++ interface and a five disk software raid 0 that can do about 150 > MB/s. I can easily run at 25 MHz with a simple nop_handler that only > checks for underruns and timestamps continuity, but when I write to > disk, I can barely do 10 MHz for longer than 30 s without overruns. I > have tried just about every filesystem with the same result every > time. Try setting your application to run using real-time scheduling priority. This is done in C++ via a call to: gr_enable_realtime_scheduling() or from Python: gr.enable_realtime_scheduling() Check the return value to ensure that it worked, it should == gruel::RT_OK from C++ or in python gr.RT_OK. You must have permission to do this, either by virtue of running as root, or by allowing your user/group to do so by adding a line to /etc/security/limits.conf: @usrp - rtprio 50 Then add your username to the 'usrp' group (which needs to be created if it doesn't already exist.) > Why is there a (int)(MAX_SLAB_SIZE/sizeof(void*)) limit? We use the Linux kernel packet ring method of receiving packets from sockets. This is a speed optimized method that maps memory in such a way that the kernel sees it as kernel memory and the user process sees it at its own memory, so there is no copying from kernel to user space. It also lets us receive multiple packets with one system call. (At full rate, we process about 50 packets per system call.) The kernel maintains a ring of pointers to pending packets, and these ring descriptors must be stored in one kernel memory region. These memory regions are of MAX_SLAB_SIZE, and each descriptor is sizeof(void*). So the tp_block_nr variable calculates the number of possible packets by dividing the buffer length by the block size, and if that is more than can be stored in MAX_SLAB_SIZE, it reduces it to the limit that imposes. So you probably aren't using all 500 MB of that memory. You can uncomment the debug printf in that part of code to see the number of blocks actually allocated. What tends to happen if you aren't running your user process as RTPRIO is that the libusrp2 driver grabs the packets from the kernel okay, but your flowgraph doesn't read them from the driver fast enough, and you get backed up into an overflow. Johnathan _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio