[USRP-users] Debugging late Samples and Underflows
rjm96 at bu.edu
Mon Oct 30 12:34:27 EDT 2017
So I've been reading the Ettus docunmentation pretty heavily, and I've
tried several of the steps. I just have a handful of quick questions from
1) For an underflow, it mentions samples not being produced fast enough
(which is more or less the definition of an underflow). Is there a good way
to double check that the samples are being generated fast enough? I can use
a Time Sink and Freq Sink without any issues, although I suppose this may
be a good case to verify again with performance counters?
2) Towards the bottom of the page, it lists "rx_missed_errors" as an
example of when a Intel PCIe's bus cannot keep up (I know it may not be a
cause, but I'm experiencing the errors with Intel CPUs AND AMD CPUs). Is
there a solution around this or another method to verify this may be the
cause? For the record from a text document produced by ethtool -S enp2s0f1
> ethtool_test.txt, I have following (abridged)
If needed I could also post the whole thing.
And finally 3) What do you mean by "Incorrect/invalid time_spec provided.
"? I don't think I set in grc any time_spec
I'm using Ubuntu 17.04, Intel® Core™ i7-6900K CPU @ 3.20GHz × 16 + GeForce
GTX 1080 Ti/PCIe/SSE2 + 62.8 GiB memory (which should be fast enough to
easily 2MHz sampling rate), UHD 3.010.002 (master, but I have the same
issue on other branches and versions), GNU Radio 3.7.11, and USRP X310s (I
experience Late packets on any flowgraph with more than 2 USRPs). Each USRP
is just transmitting sine wave generated by a signal_source in gnuradio.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users