[USRP-users] performance issues

Per Zetterberg perz at kth.se
Mon Nov 29 10:52:23 EST 2010

On Mon, 2010-11-29 at 01:42 -0500, Josh Blum wrote:
> On 11/28/2010 03:39 PM, Juha Vierinen wrote:
> > Hi,
> > 
> > I recently upgraded to the newest protocol 7 of uhd. I noticed that I
> > am having trouble getting all the packets in.
> > 
> Nothing drastic in the receive path (to the host) has changed for quite
> some time. Especially if transmit is not involved. So I am befuddled.
> > When I run benchmark_rx_rate, I notice that even with 4 MHz, the
> > process is taking over 50% of the CPU time, and at 25 MHz it is taking
> > 150 % (it is threaded I guess). Why is this? The usrp1 only takes
> > about 15 % of the CPU time when running at 5 MHz, even when writing
> > everything to a file.  I rember the gnuradio driver used much less CPU
> > resources. What is going on?
> > 
> There is a thread in the receive path that inspects packets and places
> them into a queue. You are most likely seeing the extra overhead (vs
> gnuradio) of this thread. I am looking into removing it in the near
> future if doing so decreases the CPU overhead.
> Greater overhead is just a reality given the additional features w/ UHD,
> but it should not be drastic. I can look into this more when I get back
> into town.
> > Is there e.g., any way to increase the packet size? I have a hunch
> > that this might help.
> > 
> You can bump up the recv_frame_size
> http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters
> Assuming your network card can handle frames over 1500 bytes, the USRP2
> can output frames of up to 2048*4 bytes including transport headers (I
> believe).
> -Josh
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

I also have great problems with the latest version. My UHD is now
2568ef ... used to be f7966...

Before I was able to transmit frames between my two laptops with a
interspacing of 6ms without underruns/overruns. The same code now needs
100ms and HAS underruns/overruns. I really need the old performance
back ....


More information about the USRP-users mailing list