Re: [Discuss-gnuradio] Flowgraph latency with UHD and continuous stream

[Jordan Otomo]

The payload field contains the sequence numbers of packets consumed by the USRP's DUC.  As a note, you may need to reorder the bytes (uhd::ntohx).  I'm handling the messages in C++, so I'm not too sure about the swig.  My source reads the messages and calculates the number of samples consumed by the USRP (this is possible because the USRP packet size is fixed).  The number of produced output samples are limited such that there are only N samples (50 ms) between my source and the USRP's DUC. 

On Apr 23, 2013, at 4:37 PM, Phelps Williams wrote:

Thanks Jordan, this is super helpful.  

I made the uhd/gr-uhd changes that josh suggested and using the following code snippet.  I now can see EVENT_CODE_BURST_ACK (event code == 0) messages coming back from UHD at approximately 30msec intervals.

self.async_msgq = gr.msg_queue(0)

self.uhd_amsg_source_0 = uhd.amsg_source("addr=192.168.102.1", self.async_msgq)

self.async_rcv = gru.msgq_runner(self.async_msgq, self.async_callback)

def async_callback(self, msg):

    md = self.uhd_amsg_source_0.msg_to_async_metadata_t(msg)

    print "Channel: %i Time: %f Event: %i" % (md.channel, md.time_spec.get_real_secs(), md.event_code)

In josh's example he sets the user_payload field with presumably a buffer occupancy value.  I'm getting lost in the swiggyness here and can't figure out how to print a value of type <Swig Object of type 'uint_fast16_t *' at 0x9894188> any suggestions there?

I'm guessing what you are doing is writing a block which handles messages and in the event the occupancy drops below a certain amount, you write more source data out.

On Tue, Apr 23, 2013 at 2:17 PM, Jordan Otomo <address@hidden> wrote:

Hi Phelps,

I've been dealing with latency issues of my own, and this seems to be the best solution so far (big thanks to Josh!):

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-04/msg00211.html

The nice thing about this method is that it allows you to manage buffering at a system level as opposed to per-block.  I've been able to limit my latency to about 50 ms, but you can probably do better depending on how much processing you're doing.  Hope this works for you!

Jordan

On Apr 22, 2013, at 10:59 PM, Phelps Williams wrote:

I created a block which in the work(), sits in select on a udp socket with a timeout of 10msec.  In the event it times out rather than getting a read signal, a pattern of noutput_items is written.  In the event it receives data from the udp socket, the udp dgram is copied to the output items vector.  This flowgraph ends with a UHD USRP sink.

I am consistently observing latency through my flow graph of around 2 - 2.5sec.  The total latency doesn't appear to be dependent on the sample rate (I've tested 1Msps and 2Msps).  When intentionally underruning the flow graph by setting set_max_noutput_items to less than 10msec of samples, the latency through the graph is between 80msec and 200msec.  Intentionally underrunning UHD isn't an option for my application as an intermittent modulated signal from the USRP causes issues.

I am attempting to use the global (via gr.top_block.start()) and block specific max_noutput_items settings to limit the total amount of latency in my flow graph but this doesn't appear to be the primary source of latency.

My suspicion is that UHD or the USRP has a transmit buffer which is the source of my problem.  I tried messing with the send_buff_size and recv_buff_size specified here: http://files.ettus.com/uhd_docs/manual/html/transport.html but these didn't seem to make any impact.

I played with setting set_max_noutput_items on the source block to the exact value expected during the 10msec select timeout in my custom source block.  This works for a while but occasionally underruns.  Also as udp traffic moves through the block, the total amount of latency slowly increases.  It also seems wrong to throttle the flowgraph at both the source and the sink.  Much like it is problematic to use a throttle with a UHD source or sink block.  set_max_noutput_items doesn't seem like the right solution for this problem.

Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant improvement but it isn't a viable option for my application because it is a universal setting for all gnuradio based radios running on my system.  Some of which require the default buffer size to operate efficiently.

There has been a little discussion of this topic on the mailing list in the past but I haven't found examples that include UHD / USRP with a flowgraph that isn't intentionally underrunning (ie with a typical UDP source block).

I have messed with the maximum socket buffer sizes allowed by linux.  The uhd recommended config and much smaller variations don't appear to make an impact to this latency.

$  sudo sysctl net.core.rmem_max

net.core.rmem_max = 50000000

$ sudo sysctl net.core.wmem_max

net.core.wmem_max = 1048576

For reference I am running:

UHD 003.005.002

Gnuradio 3.6.4.1

tl;dr

My expectation is that there is a buffer UHD is attempting to maintain, when this buffer gets low, it triggers upstream work operations in the flowgraph to refill this buffer.  Is this not the case?  How can I manipulate the size of this buffer?  Is there any way to confirm the size of this buffer?

Thanks!

-Phelps

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio