Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[Marcus D. Leech]

On 05/02/2016 10:40 PM, John Shields wrote:
> Hi,
>    I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
> N200 with SBXv3. I have been using the aptly-named and highly useful 
> Simple_ra though I believe this is orthogonal to the issues I am seeing.
>
> when I run simple_ra with :
>
>  simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 10000 --devid 
> uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 
> --longitude 172.570277777 --latitude -43.519444444 --spde
>
> the system runs along happily for several maybe even up to 20 odd 
> hours but, as below, I start to see one or more Ds. In one run of 23 
> hours, I had 10 Ds and eventually a segmentation fault - not sure if 
> it is coincident with issuing of the final 'D'. Sometimes the D is not 
> accompanied by UHD errors
>
> here is the terminal output from the last run:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>
> Using Volk machine: avx_64_mmx_orc
> gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
> airspy redpitaya
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Detecting internal GPSDO.... Found an internal GPSDO
> -- Setting references to the internal GPSDO
> -- Using subdev spec 'A:0'.
> -- Using LO offset of 1e+07 Hz.
> WARNING: Overriding original sample rate of 1e+07 with 2e+06
> -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
> D
> UHD Error:
>     Control packet attempt 0, sequence number 10594:
>     RuntimeError: no control response, possible packet loss
>
> UHD Error:
>     Control packet attempt 1, sequence number 10595:
>     RuntimeError: no control response, possible packet loss
>
> UHD Error:
>     Control packet attempt 2, sequence number 10596:
>     RuntimeError: no control response, possible packet loss
>
> UHD Error:
>     An unexpected exception was caught in a task loop.
>     The task loop will now exit, things may not work.
>     RuntimeError: link dead: timeout waiting for control packet ACK
> Terminated
>
>
> I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
> 15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
> subnet and NIC.
> Apart from setting:
> net.core.rmem_max = 50000000
> net.core.wmem_max = 1048576
>
> I have not 'tuned' any os settings. When the application is running, 
> the 8 cores are between 40-50% utilised.
>
> When I restart simple_ra after the error, it runs again fine until it 
> hits an issue n-hours in the future.
>
> Any ideas of how I can narrow down the cause of this?
>
>           Kind Regards,
>
>                    John
Do you happen to know what kind of NIC you have?

Also, 2MSPS should not be chewing up much of your CPU--what kind of 
graphics card do you have?  Is this a real, or virtual, machine setup?

There Intel 82579LM is known for dropping packets under certain 
circumstances that shouldn't cause it to drop packets.  This is basically
  fatal to the way UHD does network I/O--since it uses UDP, with no 
retry mechanism (and, indeed, it's easy to see that at higher sample
  rates in particular, any TCP-like mechanism is going to cause 
heartburn for real-time flows).

If you do a:

lspci -v

It should show you what the Ethernet interface(s) are.

If this is a *server* motherboard, the underlying graphics subsystem may 
be just a framebuffer, in which case, your CPU is working really
  hard to render even simple graphics.