Forgot to mention.... For the reason I mentioned above, I typically put a time stamp on every packet I send (rather than just the first packet) so that if errors occur, subsequent packets will still be aligned. Rob
On Mon, May 11, 2020 at 4:23 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
