[USRP-users] Sending very short bursts with RFNoC on X310
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
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.
> 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