> 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
