[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Josh Blum
Subject: Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Date: Tue, 01 Mar 2011 16:01:23 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

On 03/01/2011 03:25 PM, Feng Andrew Ge wrote:
> Josh,
> Everything is in the attachment, look for python-based UHD_* code.
> The performance before and after Feb.25 was both poor. At one point
> before Feb. 25, the latency was even worse, up to >30ms. But I forgot
> the time.
> In terms of GNU Radio, for running UHD I checked out next from GNU Radio
> git.  However, for raw Ethernet, I only ran GNU Radio 3.3.0.  I haven't
> found time to check GNU Radio changes yet, what might cause such huge
> performance drop.


Here is an idea that may explain your problem:

When the raw ethernet source calls into work(), it does not attempt to
fill the entire buffer (noutput_items). Rather, it waits at least one
packet to become available and then copies only the data that is
available immediately into the buffer.

In contrast, the UHD work function is bandwidth optimized and tries to
fill the entire buffer. At your sample rate (500ksps), this will impose
serious delays for very large noutput_items (10s of thousands). I hope
that explains the issue you see.

I am going to attempt a modification to the work function, where we recv
a single packet with timeout, and then anything else that is available
without waiting.

I will let you know when I post a branch with changes.

> Andrew
> On 03/01/2011 06:13 PM, Josh Blum wrote:
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]