So, then it sounds like you could use the stock version of benchmark_rate (rather than your modified version) to demonstrate the issue. Is this correct? And, it sounds like the streaming is failing for just a single channel at 62.5MS/s? Rob
On Thu, Sep 30, 2021 at 2:13 PM Adam Bader (Proxy) <adam.ba...@oroliads.com> wrote: > Setting has_time_spec to false after the initial send shows no change in > behavior > > *Adam Bader* > > Principal Software Engineer, Orolia Defense & Security > > 1610 SW Main St Suite 202 > > Ankeny, IA 50023 > > ------------------------------ > *From:* Marcus D. Leech <patchvonbr...@gmail.com> > *Sent:* Thursday, September 30, 2021 11:41 AM > *To:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> > *Subject:* [USRP-users] Re: Amount of Radio Buffer in 4.1 > > *CAUTION:* External email to ODS > > On 2021-09-30 11:21 a.m., Adam Bader (Proxy) wrote: > > We are having issues trying to run our application with the current > version 4 releases of UHD. We are running successfully on version 3.13. > I've been trying to create a simplified test scenario using a single output > on a N310 and continue to see underruns and time errors on version 4.1. > > I'm using a modified benchmark_rate application trying to model our > streaming implementation. My testing has been on a system running Ubuntu > 18.04. The computer has a 10Gb card connected directly to port sfp1 on the > radio. The radio is running the default HG fpga image. MTU is set to 9000. > > Data is transmitted at 62.5Msps in a continuous burst. Every packet is > sent with an up to date time_spec. Our application builds up and sends 1ms > worth of samples to the radio repeatedly (trying to pass the whole ms to > send() as well as break them up into max_num_samp chunks shows no change in > timing behavior). After resetting radio time to 0 the initial packet is > time spec'd to 1.8 seconds to prime the radio buffer. There is no rx stream > involved. > > I had the sample application poll radio time in parallel with sending data > to the radio. The radio time thread prints out the result from get_time_now > every 100ms. The transmission thread prints out the time_spec that was just > transmitted once send returns. In 4.1 I can see streaming is effectively > handling everything in 'real-time'. The radio times being printed line up > identically with the time_spec that was just transmitted. Any delay in > transmission results in immediate underruns and time errors. This same test > when done with the 3.13 host library and another N310 using the 3.13 > firmware shows the sample just written being 150-200ms ahead of what the > current radio time is. > > Is there anything that can be done to increase the amount of buffer > available on the radio with the stock FPGA firmware? Is there something we > need to rethink in our streaming implementation in UHD4? Appreciate any > insights. > > > > > > *Are you able to do continuous (not-timed) streaming at 62.5Msps in your > current configuration? * > > *CAUTION:* This email originated from outside of ODS. Do not click links > or open attachments unless you recognize the sender and know the content is > safe. > _____________________________________ > The information contained in this e-mail and any attachments from Orolia > may contain confidential and/or proprietary information, and is intended > only for the named recipient to whom it was originally addressed. If you > are not the intended recipient, any disclosure, distribution, or copying of > this e-mail or its attachments is strictly prohibited. If you have received > this e-mail in error, please notify the sender immediately by return e-mail > and permanently delete the e-mail and any attachments. > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
