Hi Max (& Rob) - I'm working my way up to 2xX310. The following applies to 1x X310 + 2x SFP+ links; it -might- be applicable toward your 2x (1x X310 + 1x SFP+ link) situation; worth a try! - MLD
By default, UHD + X310 will use just a single SFP+ link for data transport, which (obviously) limits the data throughput to half that for when using both SFP+ links. The link chosen is whichever is set as "addr" in the --args. Under some conditions, you can add in arguments to use both SFP+ links. If the aggregate TX data throughput fits within one SFP+ link, then just the first "addr" link will be used, regardless of these settings. If the aggregate TX data throughput is greater than that which can be provided by a signal SFP+ link, then both links will be used -- up to total aggregate link capacity, of course. The additional arguments are: "enable_tx_dual_eth=1,skip_dram=1". --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/ On Thu, May 7, 2020 at 12:41 PM Max via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Rob, > > thank you for your comments. > > I did not think about using multiple streamers with multi_usrp, but will > give it a try before considering DPDK. > > More important, about your two questions: > Using the Replay block is not an option, 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. > > 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
