[USRP-users] Sending very short bursts with RFNoC on X310
jonathon.pendlum at ettus.com
Sat Mar 9 04:12:41 EST 2019
The DDC and the DUC (or any other block using axi_rate_change) will not
modify the packet size. Very small packets can cause underruns once the
header becomes a large percentage of the overall packet size. I'm surprised
that you are running into underruns at 20 samples per packet as that is
less than 10% header overhead. The theoretical crossbar throughput is 375
MSPS. Noc_shell's throughput is similar to the crossbar's since it also
operates on the packet line by line. Flow control packets and crossbar
switching add to the overhead as well, but there should still be plenty of
What version/branch of UHD are you using? If you are using UHD-3.13, try
setting your MTU to something closer to your actual packet size or try
As for the EOB issue, when the radio core encounters an underrun it will
stop transmitting and wait for an EOB. I wonder if the EOB never comes for
some reason, such as the DUC is not outputting it. Have you tried testing
in loopback and seeing if the DUC actually outputs an EOB on the last
On Sat, Mar 9, 2019 at 8:36 AM Nick Foster via USRP-users <
usrp-users at lists.ettus.com> wrote:
> Hi all,
> I'm trying to write an RFNoC application which generates very short bursts
> -- 20 samples or less -- which are then upsampled. I'm running into
> problems with the radio underflowing which I believe has to do with the DUC.
> I can reduce the problem to the following -- create an RFNoC graph (UHD
> only, no gr-ettus) with a radio and a DUC. Wire the DUC to the radio and
> get a tx_streamer pointing to the DUC. Set the DUC to interp=1024. Start
> the streamer via calling the radio's set_tx_streamer().
> Now send a packet to the DUC, a short one. Try 20 samples. You'll see a
> bunch of underflows come back, and if you set EOB then the radio will stop
> transmitting. (Incidentally, why is that? If I set EOB and the transmission
> results in an underflow, subsequent bursts won't transmit at all.)
> If I pull the radio out of the loop and gather the DUC output on the host,
> Wireshark shows I'm receiving a whole slew of length-88 packets. That's 20
> samples after the 64-bit header. So, it looks to me like axi_rate_change
> inside the DUC isn't resizing the output packets, it's just sending out *lots
> of them* -- in this case, 1024 20-sample packets for every input packet.
> This doesn't make a whole lot of sense to me as it's inefficient, and I can
> fully believe the radio is underflowing while trying to swallow a whole
> mess of short packets at full radio rate.
> So: is this intended behavior, and is there anything I can do to change
> that behavior besides padding my bursts?
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users