[USRP-users] Sending very short bursts with RFNoC on X310

Nick Foster bistromath at gmail.com
Sat Mar 9 19:36:50 EST 2019


Thanks for the early Saturday (or late Friday) reply.

On Sat, Mar 9, 2019 at 1:13 AM Jonathon Pendlum <jonathon.pendlum at ettus.com>

> Hey Nick,
> 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
> throughput left.

I was surprised to see 20 sample packets underrunning as well. Maybe
there's a bubble state somewhere in the DUC or the crossbar. It underruns
not only reliably but consistently in the same places, especially for short
packets. Give it a shot -- an LFTX and an oscilloscope will show that it
tends to underrun after the first few packets!

> 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
> using UHD-3.14.

This is with master (git hash 33f269f0), which is only a couple of weeks

> 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
> packet?

Makes sense. EOB comes along just fine if there aren't underruns, but when
there are, the radio never sees it.

In the meantime, I can work around the problem by just padding my bursts
with zeroes to force the packet size up. It's not ideal but I think it'll
get me going.


> Jonathon
> 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?
>> Nick
> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190309/c7b95db6/attachment.html>

More information about the USRP-users mailing list