On 2022-02-23 14:04, Brian Padalino wrote:
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.
The GNURadio test-case and benchmark_rate are only "the exact same" from
a high-level functional standpoint--the details are quiet different.
For one, there's
extra function-call overhead with gr-uhd, since it "wraps" UHD. That
*should* be trivial, depending on how things like the _recv() call
specifies transfer sizes, etc.
But in addition, Gnu Radio turns *every block* into its own thread, and
it has an exotic ring-buffer manager between blocks. So, the
implementation details are quite
different, and I am not surprised to find that there are "emergent
behaviors" at very high sample rates.
In my opinion, something fishy is happening in GNU Radio with the X310
that is not exhibited when using benchmark_rate.
Yes, I would agree that the "stuck in overrun mode" is disquieting. It
isn't at all surprising to find that two functionally-similar test
programs have different
overrun behavior, however.
Does the "stuck" behavior change with older UHDs? I haven't seen this
myself with UHD 3.15, but I don't have any way of testing sample rates
above 25Msps myself,
nor host machines that could really tolerate that.
Brian
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
