[Top][All Lists]

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

Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy

From: Josh Blum
Subject: Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
Date: Mon, 18 Oct 2010 21:42:49 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.0.8

Hard to get objective numbers, but it seems like there's no difference
whether I have the audio sub-graph enabled or

The absolute minimum latency I can observe is about 1 second or so, with
an input recv_buff_size=2500.

I know that there's buffering in the USRP2, but not that much--32K?
  Less?  More?  Even so, at my sample rate, 32K is
   only about 20ms of latency.

The host cannot back-pressure the USRP2, and the buffering in the USRP2 itself if negligible. So, all of the backing-up that is going to happen occurs in the host when you dont read data out fast enough.

The UHD-USRP2 receive path has two buffers that fill when calls to recv() dont keep up. One is the socket buffer in the kernel, and the other is a UHD allocated buffer that hangs onto frames from the socket->receive() call. Both of those drop when filled, so any further buffering/latency you are seeing is happening in gnuradio.

You can manipulate the socket buffer size and the number of frames: http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters


reply via email to

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