Thanks Martin & Rob! We have our code working following Martin’s suggestion (set the TS in each packet, no EOB). We have seen occasional sequence errors but other than that it looks pretty good. We will give Rob’s suggestion a try. Some extra buffering could make it easier to meet our average throughput requirements by making the averaging longer. Both are good suggestions! Neal

Hi Rob and Team, I enabled the `streamer=replay_buffered` option as shown below. However, I did not notice any difference, as it still buffers 64 packets. Is there any additional configuration or step I need to take for this to work as expected?\ \ uhd::device_addr_t addr_args("addr0=192.168.30.2,streamer=replay_buffered"); uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(addr_args);\ \ Best

Perhaps the graph is not really created until you call get_tx_stream() such that you need to pass the argument to this call?? On Thu, Jan 9, 2025 at 10:24 PM <cjohnson@serranosystems.com> wrote: > Hi Rob and Team, > > I enabled the streamer=replay_buffered option as shown below. However, I > did not notice any difference, as it still buffers 64 packets. > > Is there any additional configuration or step I need to take for this to > work as expected? > > uhd::device_addr_t > addr_args("addr0=192.168.30.2,streamer=replay_buffered"); > > uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(addr_args); > > Best > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

On Fri, Jan 10, 2025 at 6:19 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Perhaps the graph is not really created until you call get_tx_stream() > such that you need to pass the argument to this call?? > That's right, this is a stream arg, not a device arg. See here: https://uhd.readthedocs.io/en/latest/page_configuration.html#config_stream_args_args Note that this only works with multi_usrp, not with RFNoC API. --M

Thank you both! \ This allows me to buffer \~100 packets of 1996 samples instead of 65. \ \ For others:\ stream_args.args\["streamer"\] = "replay_buffered"; // Add more "elasticity" on Tx using the Replay block as FIFO in USRP

Interesting. I would have expected approximately 125K packets could be stored in this FIFO given that it is 1GB and the packet size is perhaps 8000 bytes. The DRAM memory is equally divided up in order to support multiple channels with a FIFO for each channel. This memory allocation algorithm is based on the number of replay blocks and ports, but I don't know if it matters only how many ports the replay block has available or how many ports are in use in the current graph. In any case, since your experimental results are no where close to 125K packets, I wonder if there is a different bottleneck such as the packet context FIFO. If so, then a rebuild of the X310 image with bigger context FIFOs would support much larger buffering. Rob On Tue, Jan 14, 2025 at 8:57 PM <cjohnson@serranosystems.com> wrote: > Thank you both! > > > This allows me to buffer ~100 packets of 1996 samples instead of 65. > > For others: > stream_args.args["streamer"] = "replay_buffered"; // Add more "elasticity" > on Tx using the Replay block as FIFO in USRP > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >