Re: [Discuss-gnuradio] USRP tx_time tags and late packets

[Stephen Larew]

As of now, reverting to UHD 3.9.6 from 3.10.1.1 has fixed our late and 
underflow issues.  We’ve experimented with buffers between blocks to minimize 
latency, but what we have now (top_block.start(<somesmall#>)) is satisfactory.  
We switched to scheduling packets according to the USRP clock and not the host 
clock and that is working well.

-Stephen

> On May 9, 2017, at 23:58, U L <address@hidden> wrote:
> 
> I'm surprised no one responded to this.  My group has had some experience 
> with this.
> 
> We found latency can be extremely large for packetized transmits, especially 
> if the packets are small.  Without modification, there is a minimum buffer 
> size GNURadio sets regardless of the buffer size settings in blocks (or 
> top_block).  This means packets will build up in the output buffers of every 
> block b/w source and sink.  Even the solution collecting packets will still 
> have large latency because the output buffers are again filled with packets 
> before being sent out.
> 
> What you might be able to do.
> 1.  Modify the minimum buffer size.  This is non-trivial, the correct 
> implementation will maintain the minimum buffer size for efficiency but 
> essentially manage a sliding window across the larger buffer, whereby the 
> window size is the desired buffer size.  This is prob. the solution to #3.
> 2.  Use PDUs everywhere such that you can propagate packets at the generation 
> rate and not build up a queue before the sink.
> 
> We were able to get latency down with option 1.  I asked my colleague who 
> performed experiments with a USRP N210 on a moderately powerful laptop.  The 
> flowgraph was usrp source to usrp sink and he correlated the signal running 
> into and out of the USRP.  With real-time scheduling and high thread 
> priorities and small buffer size he was able to get 1 ms in-to-out latency @ 
> 2 Msps sample rate.
> 
> One other tip: the PC clock and USRP clock are not in sync.  If you want 
> precisely timed transmissions, you need something monitoring the internal 
> clock of the USRP.  You may be able to do this by querying the time 
> periodically.  I believe you can do this through the command interface: you 
> request a time tag to be output on a usrp source stream.  You can then keep 
> time by counting samples from the source tag.
> 
> Good luck, I hope you make some progress and report it here.  I for one would 
> be very interested.
> Jared.
> 
> 
> On Tue, May 2, 2017 at 8:28 PM, Stephen Larew <address@hidden> wrote:
>> Answering “question” #1 that I asked below: it looks like I can use 
>> gr::uhd::amsg_source to get the UHD async_metadata_t.  I will experiment 
>> with that for now, but questions #2 and #3 still stand for me.
>> 
>>> On May 2, 2017, at 16:33, Stephen Larew <address@hidden> wrote:
>>> 
>>> I am having trouble with late packets at the USRP.  I am working on a TDD 
>>> system with GNU Radio and x310 radios.  I understand that I should use SOB 
>>> and EOB tags to delimit a packet and add the tx_time tag to control 
>>> transmission time.
>>> 
>>> Current approach: In the source block, I set the tx_time tag to a point 
>>> that is in the future relative to the host computer’s clock, which was 
>>> synchronized with the USRP at program startup.  The samples flow through 
>>> the graph and get to the usrp_sink block for transmission.  The latency in 
>>> the flowgraph seems to vary enough such that some packets are late (UHD 
>>> prints ‘L’) while other packets are not late.  I have set max_noutput_items 
>>> when calling top_block.run() to try to bound the latency, but with limited 
>>> improvements.
>>> 
>>> 1. In GNU Radio using stock usrp_sink, is there a method of getting the 
>>> late flag without having to monitor stdout and parse Ls? I recently read on 
>>> USRP-users that the proper way to detect late packets is to look at the 
>>> metadata returned from uhd’s send function. Does the usrp_sink block 
>>> publish this in some way?
>>> 
>>> 2. Any tips for doing *tightly timed* TDD in GNU Radio in general?  For 
>>> example, we are experimenting with a) setting tx_time at the source block 
>>> (requires predicting the flowgraph’s processing delays in order to not be 
>>> late at the USRP) and b) setting tx_time at a custom block just before the 
>>> usrp_sink so that most of the flowgraph processing delays are not a factor 
>>> when computing a tx_time.  What approaches have been taken by others?
>>> 
>>> 3. When or why would supplying a max_noutput_items to top_block.run() not 
>>> be passed on to or respected by blocks in a flow graph?  My colleague 
>>> observed that noutput_items given to work() was greater than what was given 
>>> to top_block.run().  Do tagged stream blocks change the scheduler behavior 
>>> w.r.t max_noutput_items?
>>> 
>>> -Stephen