On Wed, Feb 23, 2022 at 1:03 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote:
> On 2022-02-23 12:00, zlika_...@hotmail.com wrote: > > > > Thanks for your answer. > > > > I tried to use benchmark_rate, and I don’t have any sample loss at > > 200MS/s. > > > > On GnuRadio with a very simple flowgraph (USRP Source -> Null Sink) I > > still have very regular (every few seconds) overflows. > > > > In both cases, the CPU load of each core never goes over ~25%. > > > > Is there any particular performance tips to know on GnuRadio (e.g. > > playing with the min/max output buffer sizes of the blocks) to > > optimize the throughput? > > > > > A Gnu Radio flow-graph will *NEVER* be as performant, for "simple > things" as a hand-coded equivalent, because it has extra overhead in > managing buffers and threads > and so-on. > While this may be true in general, the test case is said to be (USRP Source -> Null Sink). This is the most trivial case and should basically be the exact same as what benchmark_rate is running, and yet GNU Radio has overflow whereas benchmark_rate does not. When I was testing this, another interesting thing happened where once an overflow occurred in GNU Radio, it never recovered and it was O all the time and with a very low/strange sample rate coming in - as if something was stalled in the pipeline on the radio and repeatedly thrashing some state. That is, until I ran benchmark_rate. Once benchmark_rate was able to run properly, GNU Radio was able to run fine until the next O. This is with GNU Radio maint-3.10 and whatever is built in with gr-uhd linked against UHD 4.10.5 I believe. In my opinion, something fishy is happening in GNU Radio with the X310 that is not exhibited when using benchmark_rate. Brian
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
