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.
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. 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? Jonathon On Sat, Mar 9, 2019 at 8:36 AM Nick Foster via USRP-users < usrp-users@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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
