[USRP-users] performance issues
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
> 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
> USRP-users mailing list
> USRP-users at 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
More information about the USRP-users