Hi Jason, I'm not sure if your issue has been resolved or not. There is a known issue in UHD 3.10.0.0 and later where buffer sizes that are not aligned with the maximum number of samples per transfer can result in underruns. We are working to fix it, but there is a simple workaround. Size your TX buffer to some multiple of the value returned by tx_streamer::get_max_num_samps() and the underruns should go away.
Regards, Michael On Thu, Aug 31, 2017 at 8:11 AM, Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Jason, > I downloaded and compiled your program. Here are some remarks. > > - I accidentally ran your program using UHD 3.9.LTS. It worked fine! > It even worked fine with Num Channels set to 2. I then realized my mistake > and switched to 3.10. > - I duplicated your results using UHD 3.10. That is, bad behavior > with same channel for Tx/Rx and good behavior with different channels for > Tx/Rx > > Regarding 3.9.LTS, if this is an option for you, I would highly recommend > it. We have had issues with 3.10 and thus we only use it when necessary. > It is necessary for either working with the TwinRx daughterboard or if you > need dual 10Gbe links. Note that a single 10Gbe link can support aggregate > 300 MS/s so it can handle 2 channels at 100 MS/s. But, it can't do 2 > channels at 200 MS/s which is why you might need dual 10Gbe. > > I didn't investigate whether or not I could run the example > tx_rx_loopback_to_file program successfully and if so why it succeeds while > your program fails. > > Let me know if you have any questions / comments. > > Rob > > On Wed, Aug 30, 2017 at 7:06 PM, Jason W Zheng <jason.w.zh...@aero.org> > wrote: > >> Hi Rob, >> >> >> Thanks for your suggestion. I tried adding set_thread_priority_safe(), >> but it didn't solve the problem. >> >> >> -Jason >> ------------------------------ >> *From:* Rob Kossler <rkoss...@nd.edu> >> *Sent:* Wednesday, August 30, 2017 8:02:25 AM >> *To:* Jason W Zheng >> *Cc:* usrp-users@lists.ettus.com >> *Subject:* Re: [USRP-users] Buffer underruns on x310 when transmitting >> and receiving from same channel cont. >> >> Jason, >> This is perhaps a long shot but I noticed that your code does not include >> set_thread_priority_safe() for each thread - only the main thread. Perhaps >> adding this will help. I realize that this does not explain why you are >> successful when not using the same channel. >> >> Also, I noticed that the example tx_rx_loopback_to_file.cpp does not >> implement this call on the Tx thread. The Rx occurs in the main thread >> though for this example. However, I see in "benchmark_rate.cpp" this call >> is implemented for both Tx and Rx threads. >> >> Rob >> >> >> On Thu, Aug 17, 2017 at 6:55 PM, Jason W Zheng via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> The last thread got a little long and kind of died, so I decided to make >>> a new thread summarizing all the findings thus far. >>> >>> >>> I'm running on an x310 across dual 10 Gigabit ethernet, outfitted with >>> twin basic tx rx daughbords. I'm running on UHD version 3.11.0. Ideally, I >>> would like two simultaneous transmit and receive streams, utilizing both >>> channels to transmit and receive. I don't want to have to use 2 x310s for 2 >>> receive and transmit streams >>> >>> >>> When I transmit and receive at the same time on the same channel, I get >>> a lot of U's printed out to console signaling underflows, no matter what >>> the rate. *HOWEVER, if I transmit and receive on separate channels, say >>> tx_streamer has stream_args at channel 1 and rx_streamer has stream_args at >>> channel 0, it works just fine.* >>> >>> >>> I've attached the source code of a complete but simple program that will >>> hopefully demonstrate my problem. In this program, two threads are created: >>> a transmit thread and a receive thread. The receive thread is constantly >>> receiving data to a buffer and overwriting that buffer with new data. The >>> transmit thread is constantly transmitting 0's from a prefilled buffer. >>> >>> >>> If anyone has an x310 running across 10Gbps ethernet, can you compile >>> and run my program to test if this problem occurs not just for me? >>> >>> >>> Here's what we have already tested: >>> >>> - I'm running on a server system rocking two 12 core intel xeon >>> processors. (https://ark.intel.com/products/91767/Intel-Xeon-Processor-E >>> 5-2650-v4-30M-Cache-2_20-GHz). My network card is the recommended x520 >>> da2. Someone had previously suggested NUMA to be an issue, but I don't >>> think this is the case as the program works when we switch to transmitting >>> and receiving on separate channels. >>> >>> >>> - I've tested only transmitting and only receiving. We can transmit at >>> 200MS/s across both channels and we can receive at 200MS/s across both >>> channels, but we cannot transmit and receive from the same channel. This >>> suggests our network card is working properly and we can handle the high >>> rate. >>> >>> >>> - I've tried my program on UHD 3.10.2 and the problem still occurs >>> >>> >>> - I've tried setting the tx_metadata waiting 2 second before >>> transmitting. The problem still occurs. >>> >>> >>> - I've tried running the example program txrx_loopback_from_file and >>> that works for simultaneous receive and transmit, but I have no idea why. >>> >>> >>> From the last point, I'm lead to believe that I am somehow calling the >>> uhd API wrong, but I have no idea where the error is. Any help would be >>> greatly appreciated. >>> >>> >>> Thanks, >>> >>> Jason >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
