Hi Eugene, a couple of things that might clear things up:
- If you are building the DMA FIFO, then yes, it's just a FIFO. Rob was referring to the buffered mode, which makes the replay block behave like a FIFO, but the DMA FIFO block is a true FIFO. In that case, ignore that last paragraph of mine. - Not everyone knows how to build custom bitfiles, so I get more questions on the standard images that use replay blocks. - If you use a DMA FIFO block in GNU Radio or elsewhere, you still need to connect it. After that, it's more or less transparent. - But even if you use a DMA FIFO block, you still care about the SEP buffer size, because that is *not* in DRAM. - And yes, if you use additional FIFOs, the latency goes up. Hope that clears things up. --M On Mon, Mar 2, 2026 at 10:56 PM Eugene Grayver <[email protected]> wrote: > Hi Martin, > Based on your last response, I am a bit confused: > > - Using the replay as FIFO directly is not going to work. > - I was going to rebuild the FPGA using the DMA FIFO (not the replay > buffer) > - With the DMA FIFO: > - Latency goes up > - This should be transparent to UHD/Gnuradio API — it just appears > as a larger input buffer. Is that correct/ > > > Thanks > > You say: > " > Yes, but the flow control loop operates on the smaller Tx buffers. The idea > is that the replay/DRAM will be able to always drain the Tx buffer, and > therefore improve throughput because unlike the radio, it can always > consume very quickly. > In practice however, if the host sends out Tx buffer size data, it will > still wait to send more data until it receives flow control credits from > the FPGA. Because those have to come over the network, there might still be > a delay and that can add to the overall latency and cause issues with > throughput. > Also, when we say the "replay block is acting as a FIFO", it's really only > acting as if, like you say. The way this is implemented with > replay_buffered is by the host sending out lots of stream commands to the > replay block. > " > > ------------------------------ > *From:* Rob Kossler <[email protected]> > *Sent:* Tuesday, January 27, 2026 11:15 AM > *To:* Eugene Grayver <[email protected]> > *Cc:* usrp-users <[email protected]> > *Subject:* Re: [EXTERNAL] Re: [USRP-users] TX DRAM buffer > > I think that you need to include the tx streamer arg "replay_buffered" or > perhaps "streamer=replay_buffered" > > > https://github.com/EttusResearch/uhd/blob/ab8ec9973324299828d48d7a27258939dd6ca837/host/lib/usrp/multi_usrp_rfnoc.cpp#L415 > > > On Tue, Jan 27, 2026 at 1:59 PM Eugene Grayver <[email protected]> > wrote: > > Thanks. I saw notes that seem to indicate that option. Anyone at Ettus/NI > care to chime in as to how to do it? I found an example for E320 that > shows an RFNoC .yml with a dram FIFO. I could make one for N320, but it is > not clear how to use it from gnuradio. > ------------------------------ > *From:* Rob Kossler <[email protected]> > *Sent:* Tuesday, January 27, 2026 6:45 AM > *To:* Eugene Grayver <[email protected]> > *Cc:* usrp-users <[email protected]> > *Subject:* [EXTERNAL] Re: [USRP-users] TX DRAM buffer > > > *Do not open links or attachments unless you recognize the sender. If > unsure, click the Report Phish button or forward the email to OPSEC. * > Hi Eugene, > I "think" that the replay block can act as a FIFO in recent UHD images. > But, there is a possibility I am wrong such that there is a build-time > parameter that is needed to config this. Another option would be DPDK if > you are not already using it. > Rob > > On Mon, Jan 26, 2026 at 7:00 PM Eugene Grayver <[email protected]> > wrote: > > Hi, > > The default TX buffer for N32x is 128k samples = 512 kB. The box has 1 GB > of DRAM. I am getting occasional underflows when streaming at 200 Msps, > even though the CPU is not very loaded and easily meets the average > throughput. > > I have done all the usual stuff — isolated cores, pin threads to cores, > etc. > > Is there a way to increase the default DRAM buffer size w/out rebuilding > the FPGA image? > > Thanks. > > Eugene Grayver, Ph.D. > Principal Engineer > 310-336-1274 > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
