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

[Feng Andrew Ge]

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.

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 
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?

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?

Andrew


On 03/01/2011 04:18 PM, Josh Blum wrote:
> 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.