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