I have seen the "stuck" behavior, although it was about a year ago and I doubt
I could reproduce it again. It occurred as I streamed two Rx inputs at 20 MSPS
on a B210 to a Raspberry Pi 4 USB 3.0. It was model v1.1, which has known
issues in the hardware implementation of USB 3.0. The pi is up to v1.4 now.
--page
--
page heller
On 2/23/2022 1:48:52 PM, Marcus D. Leech <patchvonbr...@gmail.com> wrote:
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
[01d33f63-e467-4d8a-b295-2169fb08b6e8]
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
