It sounds like something isn't right. The streamers should automatically backpressure. That's how it works with the radio, and it should be the same for a custom block connected to stream endpoints.
We have seen cases where host ethernet interfaces can't keep up when you start approaching the line rate of Ethernet (e.g., 10 Gbps) so they drop packets, which show up as sequence errors on the RX streamer. What kinds of rates are you getting across each interface? Is this over 10 GbE? Any chance the "ready" signal isn't being used properly in your block to allow back-pressure? The block needs to deassert tready to tell the stream endpoint to backpressure the streamer. Wade On Fri, Mar 24, 2023 at 9:41 AM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I developed a custom RFNoC block and was testing it with a graph that was > essentially: > tx_streamer => myblock => rx_streamer > > This works fine unless I send a large number of samples, in which case bad > stuff happens in terms of sequence errors, timeouts, etc (i.e., the typical > streaming at high speed woes). > > In the case of a Radio that must stream output samples at a fixed rate, I > can easily understand the need for keeping up on the host side. But, for > my case where I am just streaming through a custom block that does not care > about sample rate, it would be nice if backpressure could handle the host > rate variations. > > In order to make things "work", I have inserted a "sleep" statement in my > transmit loop to purposely throttle the Tx rate so that the Rx could keep > up. This works well enough but in order to get reliable streaming I am > forced to throttle more than I would like. So, I am wondering if anyone > has ideas on a better way to handle this. > > It seems that the host Rx gets overwhelmed and cannot backpressure my > block. I don't quite understand why because if there is no backpressure, > how do we get "Overflow" when the radio has no place to put incoming > samples "because of backpressure"? > > Rob > _______________________________________________ > 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