My own experience is that 200 S/s on two channels is very difficult to achieve from the host. Separate streamers may help, but you will likely need to move to DPDK to get the best performance. I have not tried DPDK recently, but when I tried it a few years ago, the performance was excellent, but it was not easy to get it working properly (and there were some negative side effects that I never solved). The "skip_ddc" and "skip_duc" do not have any effect on FPGA images that are "statically linked" between the Radio and DDC/DUC (which is likely all UHD 4 images).
On Tue, Jun 13, 2023 at 12:40 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 12/06/2023 22:03, Aaron Smith wrote: > > Hello All, > > > > I am trying to transmit on two UBX-160 daughterboards within a single > > X310 at 200 Msps using UHD 4.1.0.5-3. > > > > I am experiencing periodic underflows, and I have already applied all > > of the tips in the "USRP Host Performance Tuning Tips and Tricks" > > application note, with the exception of using DPDK. > > > > I have a few questions about UHD streaming and what can be done to > > improve performance. > > > > 1. My current implementation uses a single tx_streamer for both > > channels, and uses multiple threads to populate the buffers sent to > > the X310. Would the performance be better if I used two separate > > streamers, one for each channel, in separate threads? > I don't think there's a closed-form answer to this. Because it would > depend on your particular system, application, etc. I'd > just do the experiment and see... > > > > > 2. I have seen some claims that DPDK is not as useful with UHD 4, is > > this true? > I don't use DPDK myself, so I don't know if that's true or not. > > > > > 3. With UHD 4, would it help to set the skip_duc and skip_ddc flags > > with full rate streaming? > Again, the answer here is susceptible to experiment... > > > > > 4. Are underflows only created within the send() function? Or can the > > timing of calls to send() cause underflows, especially when the burst > > flags are used? For example, suppose I set the start of burst flag to > > true for a single buffer containing 1 second of data, and then I > > toggle the start of burst flag to false for subsequent buffers and > > continuously call send() on 1 second buffers for 10 minutes. On the > > last second I set end of burst flag to true. The idea is to create a > > 10 minute long "burst." If I call send late on one of the one second > > buffers in the middle of the "burst" will UHD report underflows? My > > thinking is the X310 should think it is in the middle of a burst, and > > will expect data, but send() has not been called, so there is no data > > for the radio to read from the host, creating underflows. Perhaps I am > > also misunderstanding the purpose of the burst flags, as they are not > > well documented. > > > > Thanks for the help! > > Armon > > > Underflows occur when the radio hardware underflows its FIFO, which in > turn means the host isn't providing samples at > the desired rate--the radio has no idea what your "send()" boundaries > are, just that it isn't getting samples when it needs > them. The data in the "send()" has to percolate through UHD, > through the kernel IP stack (or DPDK stack) and its buffers, and > then the hardware buffers. Any information about exactly when you > called "send()" is pretty invisible by the time it reaches > the radio. > > The "burst" architecture is really intended for applications like TDD or > half-duplex, where you need to let the radio know to > not expect any more TX samples, so it can do things like switch > antennas, etc. > > > > > > > > _______________________________________________ > > USRP-users mailing list -- usrp-users@lists.ettus.com > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
