I’m trying to remove myself from this mailing list. Sending unsubscribe to the given email does not remove me from the list. Any suggestions?
Sent from my iPhone On Aug 16, 2023, at 5:17 PM, Wade Fife <wade.f...@ettus.com> wrote:
You are correct about
INGRESS_BUFF_SIZE. It's only used to buffer data that the stream endpoint receives from another endpoint (e.g., data sent from the host computer to a stream endpoint).
There's no extra buffering in the sending stream endpoint. For normal RX where we stream to a host computer, the computer's memory serves as the buffer.
In your case, if you need extra buffering then I would expect that to be added to your block. You can change the FIFO sizes in the NoC shell to add buffering to your block, depending on the type of NoC shell you're using.
Changing the MTU on the FPGA isn't well tested, so I don't recommend changing it.
Is the overflow occurring in the radio? If that's the case, then you probably need additional buffering on the input of your block where data's received by the radio.
Wade
For my application, I am not collecting samples continuously. The radio block is commanded to stream continuously, but I have a custom block downstream which “gates” samples in bursts that pass through. I am able to at least stream data without any overflows as long as the number of samples the custom block allows is not too big, which is why I am assuming its a buffer that is too small. My assumption is as long as my buffers are large enough and the total number of samples of each burst is less than 10 Gb/s, samples should be able to unload onto the QSFP before the next burst of samples. This is why I increased the endpoint buffer sizes. However, looking over the verilog, it seems INGRESS_BUFF_SIZE only controls the buffer size of the input going into the block(before gating), and not the output(after gating), which is probably why I am still seeing overflows at the same exact rate even after increasing the buffer size. Is this interpretation correct, and if so, is it “safe” to control MTU, or will it cause other problems downstream?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
|
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
