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