On Sat, Mar 7, 2020 at 6:02 PM Marek Dopiera via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I would like to know when the buffer submitted via
> uhd::tx_streamer::send() is actually sent. The reason I need this is to
> keep some data outstanding not to starve the device, but make sure there
> is as little of it as possible (a large backlog buffered somewhere
> wouldn't allow me to change what I'm sending at the last moment, which
> is my use-case).
>
> I'm asking you for help, because I can't find a good way to do it.
>
> So far, I've come up with these options:
> 1. Artificially chop the stream into contiguous bursts and use
> tx_streamer::recv_async_msg returning EVENT_CODE_BURST_ACK to get to
> know when data actually gets sent. I'm guessing it's unwise to rely on
> contiguous bursts being sent together, though, right?
>
> 2. Use the system clock to estimate how much data is outstanding. I'm
> guessing that clock drift will be my enemy here, so it will get tricky.
>
> Neither of the options sounds like a good idea to me. Do you have any
> ideas how to cope with it?
>

I had to do this recently with an X310 application.  Originally I tried
timed bursts where I would give the full burst to UHD and hope it would get
things sent since the burst was supplied all at once.  This was not my
experience and exposed some bugs which may still be outstanding.

My next approach was to simply have a writer thread which would check a
transmit buffer/FIFO and, if there was nothing to transmit, would stuff a
minimal amount of zeros into the data stream.  This call to send() of the
zero stuffed data would fill up the buffers downstream on the device until
the backpressure from the device naturally limited the transmission.  This
approach worked very well for my application.  It kept the minimal
buffering with almost no overhead and I knew the latency through the system
was basically the amount of time to consume the buffer.

Good luck.

Brian
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to