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

[Josh Blum]

On 03/02/2011 07:37 AM, Feng Andrew Ge wrote:
> Josh,
> 
> As predicted, changing from "RECV_MODE_FULL_BUFF" to
> "RECV_MODE_ONE_PACKET" and then "RECV_MODE_FULL_BUFF" reduced the
> latency significantly. My ping RTT time was >17ms in average, now it is
> 10.5ms. This is GREAT:-)
> 

glad to hear improvement!

> Nonetheless, 10.5ms still includes quite some overhead because the
> communication time for my ping message is less than 3.9 ms in total.
> Above 6ms delay still exists somewhere.
> 

True. Can you run the tunnel application on the same gnuradio install
with the raw ethernet driver? That way we can isolate the problem. It
would be good to know if there was a regression in the scheduler, or
that the issue is inside gr-uhd.

> In your description below, "for the source, the work function waits for
> the entire RX buffer" (now it is one UDP packet of samples first and
> then the entire RX buffer), 

So, its not the entire rx buffer on the "gr_uhd_source_latency_work"
branch. The second call to recv() is non blocking, so it only handles
data that is already available without delay. It should return less than
noutput_items. You can confirm this by printing (num_samps <
noutput_items) before work() returns.


do you mean the buffer size determined by
> "noutput_items"? Likewise, is the entire TX buffer at the sink
> determined by "ninput_items"?
> 

yes (although its still called noutput_items thanks to copy/paste)

> One UDP packet of samples is only 1472/4= 368 samples and  1472/4/2/8 =
> 23 B of user data (given BPSK and 2 SPS). For a ping ICMP message ( 42B,
> which is tiny), plus 19B of frame overhead,  it still must wait for
> "waits for the entire RX buffer" which may be possibly 10s of thousands
> of samples.
> 
> Is there some way that we can further optimize the behavior? For
> example, can we limit the size of noutput_items? Is this purely GNU
> Radio scheduler's job?
> 

We can return less than noutput_items but not zero. Which is what the
changes on that branch attempt to do.

> One previous question I had is this: why *recv_buff_size*  is needed for
> benchmark_tx.py which involves only gr_uhd_usrp_sink.cc? I thought only
> *send_buff_siz* is needed.
> 

It is not needed; and whoever made that application should not have put
those options in. UHD will choose the best settings automatically.

-josh