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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio