[USRP-users] Debugging late Samples and Underflows

Richard Mcallister rjm96 at bu.edu
Mon Oct 30 12:34:27 EDT 2017


Hi all,

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
here:
http://files.ettus.com/manual/page_usrp_x3x0_config.html#x3x0cfg_hostpc_netcfg_ip

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)

IC statistics:
     rx_packets: 30167361
     tx_packets: 4959773
     rx_bytes: 1988242267
     tx_bytes: 6844509607
     rx_pkts_nic: 30167361
     tx_pkts_nic: 4959773
     rx_bytes_nic: 2121133931
     tx_bytes_nic: 6864731571
fdir_miss: 30166290
rx_missed_errors: 174613
rx_long_length_errors: 204
rx_short_length_errors: 0

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.


Thanks,
Rich McAllister
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171030/0de91add/attachment-0002.html>


More information about the USRP-users mailing list