Great. One caution though. When you do have errors, I think that if multiple channels are in a single streamer, UHD keeps them time aligned after the errors (not 100% sure though). If you have separate streamers, then if one of them has an error but the other does not, the outputs may no longer be sample synchronous. Rob
On Mon, May 11, 2020 at 4:13 PM Max <he...@email.de> wrote: > Hi Rob > > Just want to let you know that using one tx_streamer per USRP works like > a charm. > So far I've streamed continuously at 184.32 MHz for a few hours without > any underflow. I didn't test it as intensively with 200MHz, but so far > it works as well. > > So thank you for pointing me in the right direction. > > Best regards, > Max > > > Am 07.05.20 um 19:43 schrieb Rob Kossler: > >> More important, about your two questions: > >> Using the Replay block is not an option, > > Bummer. Because if you truly need to stream at 200e6 from CPU to > > host, that is pretty tough to make it work over long intervals with no > > underruns - even with only 1 device. > > > >> but I indeed forgot to add > >> clock_soure=external and time_source=external to the arguments of > >> benchmark_rate. Now if I use external synchronization, the benchmark > >> just hangs with <5% CPU usage and never finishes. > >> Running rx benchmarks however works, and I also never experienced any > >> sync issues when streaming data from two USRPs in parallel with my > >> custom application. > >> > >> I hope you asked this question because you had a suspicion. > > I just wanted to make sure that there wasn't any issue with the two > > devices having different clocks. BTW, you can also use the --pps > > command line option rather than the args "time_source" option. Both > > should work the same, I think. But, unfortunately, that was not the > > issue. > > > > Also, wanted to let you know that I just happen to have two X310/UBX > > devices by my side, so I tried your experiment and got identical > > results: > > * Rx 2x200 works fine (channels 0,2 for me) with single instance of > > benchmark_rate > > * Tx 1x200 works fine for individual channel 0 or 2 > > * Tx 2x200 FAILS when running single instance of benchmark_rate > > * Tx 2x200 works fine when running separate instances of > > benchmark_rate for the 2 channels > > > > Rob > >> > >> Regards, > >> Max > >> > >> > >>>> I have two X300 USRPs connected to the same PC by 10Gb. Both USRPs > are synchronized with 10MHz. > >>>> > >>>> I can receive data without any overflows at 200 MHz (one channel per > USRP), but transmitting results in massive underflows for 184.32 and 200 > MHz. > >>>> > >>>> benchmark_rate shows the same behavior when transmitting on both > USRPs at the same time; sampling rates <= 100 MHz or using just one USRP > however works without underflows. > >>>> > >>>> > >>>> > >>>> But I also tried running two benchmark_rate processes in parallel, > one for each of the USRPs, and this works flawlessly. > >>>> > >>>> Is there any explanation, why using uhd::usrp::multi_usrp results in > massive underflows, while operating two devices in parallel in general > seems to work? > >>>> > >>>> > >>>> > >>>> I assume using two uhd::device objects with independent tx_streamers > could be a workaround for me. But using multi_usrp nevertheless seems more > convenient. > >>> > >>> Hi Max, > >>> I don't know the direct answer to your issue, but I have a few > comments: > >>> 1) Tx Underruns have always been a much bigger issue than Rx Overruns. > >>> It is always harder to get this solved. > >>> 2) Even with multi_usrp, you can have 2 threads running. So, you don't > >>> need to have 2 device objects. I do this in my software. You can get > >>> a streamer for channel 0 and a separate streamer for channel 1 and > >>> then run them in different threads. Not quite as convenient as having > >>> a single streamer though. And, not certain if it will solve the issue > >>> for you. > >>> 3) With UHD 3.15 and earlier, using DPDK helps alot with streaming. > >>> It is a pain to get configured, but it does stream much better once > >>> properly configured > >>> 4) With UHD 4.0, I've heard that streaming is improved overall such > >>> that it might work fine without DPDK. But, that is a big question > >>> mark and there are always reasons to be cautious when jumping on to > >>> the next best thing... > >>> > >>> Two questions: > >>> 1) When it fails with benchmark rate, are you setting PPS to external > >>> so that both device clocks are set to the same time? > >>> 2) Is your Tx waveform dynamically changing or is it a fixed length > >>> sequence that is repeated? If the latter, perhaps you could transmit > >>> directly from the FPGA using the Replay block. > >>> Rob > >>> Rob > >>> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
