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

[Josh Blum]

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