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
