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.
I was honestly suprised how smooth it worked with a single USRP. I
usually see two or three underflows per hour, but that's something we
can handle.
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
Thank you for reproducing the behavior. I will now rework my
implementation to use two tx_streamers and afterwards report about the
results.
I could well imagine that keeping multiple channels synchronized, in
combination with the general challenge to not let FPGA FIFOs run out of
data, messes things up.
Max
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
