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

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 <jareddpub@gmail.com> 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 <stephen@slarew.net> 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 <stephen@slarew.net> 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

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