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? Thanks in advance. -- Marek Dopiera marek@dopiera.pl

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

On 08/03/2020 00:49, Brian Padalino wrote: > On Sat, Mar 7, 2020 at 6:02 PM Marek Dopiera via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > 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. Hi Brian, thank you for your response. I'm doing pretty much what you described - a FIFO with separate threads, and pushing to tx_stream::send until it blocks. In my case I'm actually sending data, not zeros, though. I do not have control over how much data gets into the buffers before tx_streamer::send() starts blocking, though - I'm guessing I can go lower than that, but for that to work I need to know when the data is actually sent. Thanks -- Marek Dopiera marek@dopiera.pl

On Sun, Mar 8, 2020 at 2:15 PM Marek Dopiera <marek@dopiera.pl> wrote: > On 08/03/2020 00:49, Brian Padalino wrote: > > On Sat, Mar 7, 2020 at 6:02 PM Marek Dopiera via USRP-users > > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > 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. > > Hi Brian, > thank you for your response. > > I'm doing pretty much what you described - a FIFO with separate threads, > and pushing to tx_stream::send until it blocks. In my case I'm actually > sending data, not zeros, though. > > I do not have control over how much data gets into the buffers before > tx_streamer::send() starts blocking, though - I'm guessing I can go > lower than that, but for that to work I need to know when the data is > actually sent. > The amount of buffering (software) should be controllable via arguments to UHD, and the amount of buffering in the hardware should be fixed based on which product you're using. Just for clarity, the reason for sending zeros is to maintain and keep a stream with no underflows as well as keep the buffering pipeline full since getting UHD to try to be responsive to sending bursts at a high sample rate without underflows didn't work well for me. What type of response time are you looking for when it comes to sending data versus nothing? Brian