Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

[Josh Blum]

On 03/01/2011 12:52 PM, Feng Andrew Ge wrote:
> Josh,
> 
> That's great, thanks.
> 
> When using UHD in GNU Radio, I observed huge time overhead: for example,
> using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms
> ping RTT time between two nodes; now with UHD, I have 17ms in average.
> As I increase the ping payload, the overhead time (excluding the extra
> data communication time) increases accordingly.  Since USRP2 by default
> sends data samples immediately and the RTT time between UHD and USRP2 is
> negligible, I think that the interface between UHD and GNU Radio is
> introducing some overhead.  Do you have any thought on this?
> 

The ping time is talking to the embedded cpu and is not a reflection of
the latency when dealing with data/samples. For a better explanation,
see:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000521.html


Also, make sure you pull the latest gnuradio next branch. I pushed that
diff I sent you earlier in regards to the time stamps. With the latest
change, all packets are sent ASAP in the single channel case.

> Would you tell me what threads are running in UHD when
> uhd_single_usrp_sink and uhd_single_usrp_source is called? It seems that
> at least two threads are called for each.
> 

In reference to what runs on the latest master in uhd:

For a USB device (USRP1) there is a thread running libusb async
transactions.

For a network device (USRP2/N210) there is a thread receiving async
message packets, these include flow control updates and transmit error
notifications.

The other threads you see (and the ones with any major overhead) are the
threads in gnuradio (thread-per-block scheduler)

> Is it right that the maximum amount of data that each socket.send() or
> socket.recv() can operate is dynamically determined by
> noutput_items/ninput_items from the general work function in

correct

> uhd_single_usrp_*?  Originally I thought the num_recv_frames have
> control over this; but I noticed that the UDP transport document is
> updated: "*Note1:* num_recv_frames and num_send_frames do not affect
> performance."
> 

Those refer to number of buffers allocated. But in the UDP
implementation, buffers are used and disposed of synchronously, so you
only ever need a few.

In the libusb implementation, buffers are processed asynchronously, so
you can potentially have all the buffers being emptied/filled in the
background, so altering those values may make sense to do.

-Josh