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. --M On Thu, Feb 19, 2026 at 3:48 PM Rob Kossler <[email protected]> wrote: > Hi Martin, > For my own understanding,.... Although the endpoint buffers don't use > DRAM as you pointed out, the replay block acting as a FIFO does, correct? > So, if the first block on the FPGA side of the endpoint is the replay > block, won't you achieve the goal of a large FIFO. In other words, in this > scenario, isn't it basically guaranteed that the endpoint buffer will not > fill up (prior to the replay DRAM filling up) since it will be able to dump > into the replay DRAM (and assuming that you don't exceed the DRAM > bandwidth)? > Rob > > On Thu, Feb 19, 2026 at 7:21 AM Martin Braun <[email protected]> > wrote: > >> One important thing to point out is that we do *not* use DRAM for the >> buffers, we use BRAM (of which much less is available). The requirement for >> an endpoint buffer is that we can write to it synchronously. This is not >> possible with DRAM, you must go through a memory interface, and then wait >> for your write cycle, etc. The default Tx buffers are therefore already >> close to the limit. If you want to increase it, you typically have to >> change the design (e.g., take away the buffer from channel 1 and put it on >> channel 0). But then you need to rebuild the image, which you're trying to >> avoid. >> >> The 1 GiB of PL-DRAM memory included with the N320 is fantastic for >> storing large amounts of memory, e.g., for capture/replay. The *average* >> throughput of the DRAM is also fast enough to capture both channels at max >> rate (it's just that average throughput is not the only requirement for an >> endpoint buffer). So if you can do replay/capture, then you're good. You >> can also try the replay_buffered stream arg, although it's not a silver >> bullet. It helps in some scenarios but not others, YMMV. >> >> --M >> >> On Tue, Jan 27, 2026 at 8:01 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] >> >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
