My understanding is that the buffering has changed significantly with UHD 4.x. In 4.x, the streaming flow is (host -> duc -> radio) but there is a new concept of streaming end point (SEP) between the host and DUC that provides some buffering. The buffer size is set to 32768 (could be double that amount in samples if that is for 64 bit words). There is additional buffering at the input to each RFNoC block - in this case the DUC. It appears that the DUC input FIFO is set to the MTU size (~2k or 4k samples, I think). In comparison, I *think* that 3.13 included sram fifos on the fpga as the first rfnoc block (host -> fifo -> duc -> radio). Perhaps the amount of buffering provided by these fifos was substantially larger.
On Thu, Sep 30, 2021 at 4:46 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 2021-09-30 4:40 p.m., Adam Bader (Proxy) wrote: > > My testing has been focused on a single RF channel @62.5Msps since that is > failing, but we normally run all 4 channels at that sampling rate with 3.13 > successfully. > > The benchmark_rate example as well as the sample application I wrote do > not show these failures consistently, there are occasional runs where > underruns and late commands will show up. Our application hits underruns > almost immediately after the initial time_spec passes and RF transmission > begins. > > I've been trying to investigate why we see consistent failures in our > application when nothing changes other than the version of UHD, which led > me to finding what seems like a significant change in the amount of buffer > the radio allocates. > _____________________________________ > The information contained in this e-mail and any attachments from Orolia > may contain confidential and/or proprietary information, and is intended > only for the named recipient to whom it was originally addressed. If you > are not the intended recipient, any disclosure, distribution, or copying of > this e-mail or its attachments is strictly prohibited. If you have received > this e-mail in error, please notify the sender immediately by return e-mail > and permanently delete the e-mail and any attachments. > > Given that 1msec of data at 62.5msps is only 125Kbyte of buffer, I'm kind > of doubtful that this is, per se, a buffering issue. > > Does your application set up the stream for "NUM_SAMPS_AND_MORE" or > "NUM_SAMPS_AND_DONE" or "START_CONTINUOUS"? > > What is the spacing between your 1ms bursts? > > > > >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
