Jim, Marcus, I *believe* that "skip_dram=1" will have no effect on the N310 because it does not use DRAM in the stock image (or even populate the dram-fifo RFNoC block). The definition of the stock RFNoC graph for the N310 is here <https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/n3xx/n310_rfnoc_image_core.yml> .
Most of the "buffering" for the N310 transmit path is in the buff_size of the streaming end points attached to the DUC (32768 samples) along with a small amount of buffering at the DUC (defined here <https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/duc.yml>) and at the Radio (perhaps here <https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/radio.yml>) . The easiest way to increase buffering is to increase the buff_size of the end points ep0 through ep3. But, it is possible that doing so will cause the build to fail. I don't know if Ettus max-ed these out or not. But, if the build fails, another option is to get rid of the Replay block (and associated end points) and the DDC (if you don't need it) to free up resources. Then you might be able to increase the end point buff_sizes. But, if you want to use the DRAM as a FIFO (which will provide much larger FIFOs), you should be able to just replace the 4 channel Replay block with a 4 channel DRAM fifo (defined here <https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/axi_ram_fifo.yml>), making sure to get the RAM address width (and perhaps other parameters) correct for the N310 (will be same as Replay block uses). The DRAM is 2GB so each FIFO "channel" could be configured for 125MSamples. And, back to one of my previous comments, if you have a lot of host RAM such that it would be a possibility to stream from a RAM-disk based file, I believe it would be worth a try. Rob On Thu, Apr 13, 2023 at 7:59 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 13/04/2023 18:51, Jim Schatzman wrote: > > N310 confirmed. > > > > Linux native. > > > > tx_samples_from_file produces underruns. So does a customized version of > tx_samples_from_file that uses multiple buffers and threads to guarantee > constant send pressure. > > > > I understand that the N310 should not do this. I agree that the most > likely culprit is the host computer, coupled with inadequate buffering in > the N310. Does anyone know how much buffering it provides and what the > associated timing is? That is, what is maximum lag between UDP packets > before the N310 will experience an underrun condition? > > > > In the Ubuntu host system log, there are messages during period in > question from NetworkManager. Nothing indicating a connection problem, but > consistent with my general believe that NetworkManager is an evil > abomination whose primary job is to create trouble and frustration, we will > remove it from the workstation and try again. > > > > Thanks! > > Jim > > > > > This might seem counter-intuitive, but what happens if you use the > "skip_dram=1" device argument? Do things get better > or worse? > > The N310 has 2GiB of DRAM > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
