<div dir="ltr"><div>Jonathon,</div><div><br></div><div>Thanks for the early Saturday (or late Friday) reply. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 9, 2019 at 1:13 AM Jonathon Pendlum <<a href="mailto:jonathon.pendlum@ettus.com">jonathon.pendlum@ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hey Nick,<div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>This is with master (git hash 33f269f0), which is only a couple of weeks old.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div>Makes sense. EOB comes along just fine if there aren't underruns, but when there are, the radio never sees it.</div><div><br></div><div>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.</div><div><br></div><div>Nick<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>Jonathon</div></div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 9, 2019 at 8:36 AM Nick Foster via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>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.</div><div><br></div><div>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().<br></div><div><br></div><div>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.)</div><div><br></div><div>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 <i>lots of them</i> -- 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.</div><div><br></div><div>So: is this intended behavior, and is there anything I can do to change that behavior besides padding my bursts?<br></div><div><br></div><div>Nick<br></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div>
</blockquote></div></div>