Jonathon, Thanks for the early Saturday (or late Friday) reply.
On Sat, Mar 9, 2019 at 1:13 AM Jonathon Pendlum <jonathon.pend...@ettus.com> wrote: > 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 old. > > 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. Nick > > 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
