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
