Jim, One more thought. One way to buffer data on the host side is to use OS pipes. We have used this successfully for continuous receive streaming. In /etc/sysctl.conf we set some options such as "fs.pipe-max-size" and "fs.pipe-user-pages-soft" and had separate applications - one filling the pipe and the other consuming the data. Of course, you could also create some type of buffer directly in your application (perhaps even gnuradio has a way to buffer the data read from the SSD file before sending to the N310). Rob
On Fri, Apr 14, 2023 at 10:30 AM Rob Kossler <rkoss...@nd.edu> wrote: > >> One of the things that puzzles me is that 12.5Msps just isn't that high a >> streaming rate, in fact it's totally supported over >> a *1* GBit interface. >> >> At 12.5Msps, that buffer fills(drains) in about 2.5ms. There's plenty >> of buffering on the host to buffer application scheduling >> issues, so I don't know where these underruns would be coming from. >> >> I don't really know what the OS does in terms of "transmit" buffering > (I'm slightly more confident on the OS behavior for the receive packets). I > can say that avoiding "U" has always been harder for me than avoiding "O". > My concern is that the OS is not doing much of any buffering on the Tx side > (perhaps none) such that if things pause for the 2.5ms you mentioned, then > "U" occurs. > > But, one more comment about incorporating the DRAM fifo: I noticed that > Ettus has a BIST image that uses this FIFO for the N310 (see here > <https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/n3xx/n310_bist_image_core.yml>). > So, this would be a great example to use for creating a custom image. > Rob >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
