On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: > Josh, > > First of all, I am aware of what you pointed out and I did use the code > latency_test.cpp for measuring latency between USRP2 and a host. The > latency is negligible. >
Ok, i see. You were measuring the ping time over the tunnel. :-) Can you tell me: Is this a new problem with UHD since the " February 25rd 2011" announcement. That is, was it working properly for you previously? > I think I was not clear enough in my previous email. > My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The > latency I measured is based on GNU Radio-created wireless network > interface, e.g., gr0. I started tunnel.py and created a digital link > between host_1 and host_2; then I compared ping RTT time performance > between using the UHD code and using the Raw_Ethernet code base. UHD > introduced 9 ms of overhead and I am really puzzled about this. Since I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py to UHD, can you share it? > USRP2 sends samples immediately out and the latency between the host and > USRP2 is negligible, the likely place I can think of is the interface > between UHD and GNU Radio, for example, can UDP packet sending be > preempted by other threads? Each time how many UDP packets can be > possibly sent out? > The work function is called with a randomly sized buffer determined by the scheduler. The number of packets received or sent depends on the size of the buffer when the work() function is called. I think this is exactly the same for the raw_ethernet driver. It may be helpful to print the number of items in the work function. It seems to be in the 10s of thousands of samples last I looked. When you compared UHD vs raw_ethernet driver, it was all the same version of gnuradio, correct? > Another possibility is how you allocate CPU resources in handling UHD > and what the impact might be. > > The third possibility is buffer management: how do you handle buffer > management in UHD for sending and receiving? How do data stay in those > buffers and how are data are processed, by FIFO or LIFO? If overflow > happens, will newly coming packets get simply dropped? > Nothing gets buffered in the UHD in the usrp2/n210 implementation. However, there is a kernel socket buffer on receive that has enough buffering for a second of samples. Once this buffer fills, newer packets are dropped. I also believe that this is the same on the raw ethernet driver. -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
