[USRP-users] performance issues

Juha Vierinen jvierine at gmail.com
Tue Nov 30 20:47:26 EST 2010

> 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.
> ...
> 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.

I was referring to the transition between the gnuradio usrp2 and uhd
drivers in general. I do understand that more features need more CPU
power. I am happy with all your work, but I just was wondering if
there was something wrong in my setup.

I am now using a dedicated ethernet port and I see much less dropped
packets now. I guess it is not a good idea to use a switch if you
don't want to lose packets here and there. This I guess is a feature
of UDP, although I would like to have guaranteed packet delivery for
my application.

> You can bump up the recv_frame_size
> http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters

I actually tried this, but the frame size doesn't seem to change. I
tried various different frame sizes by passing e.g.,
recv_frame_size=1300 in the multi_usrp::make parameter string.
Regardless of this, the dev->recv always gives me buffers of size 362

Also, I am pretty certain that the first packet doesn't go through.
The data seems to start 362 samples too late. The timestamp on the
first packet that comes through dev->recv also reflects this. I am
using the multi_usrp interface, the latest uhd driver and the fpga
image with version number UHD_0001.20101124180824.2568efd.


More information about the USRP-users mailing list