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