Hi Michael, thank you for the feedback. Unfortunately the X300 offers just one SFP+, so combining two links should not be possible. I also don't think the network interface itself is the bottleneck, considering two independent processes don't seem to have a problem providing the data.
I will keep you updated, how one multi_usrp instance with one tx_streamer per USRP behaves. Regards, Max Am 07.05.20 um 19:45 schrieb Michael Dickens:
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 <mailto: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 <mailto: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 <mailto: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
