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

[Marcus Müller]

On 03.05.2016 09:52, John Shields wrote:
> On 03/05/16 02:58, Marcus D. Leech wrote:
>> On 05/02/2016 10:40 PM, John Shields wrote:
>>>
>>> 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
>>>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
> Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
> 00 [VGA controller])
> ...
>     Kernel driver in use: i915
>
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
> ...
>     Kernel driver in use: r8169
>
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
> ...
>     Kernel driver in use: r8169
>
>
> 06:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit
> Ethernet (rev c0)
> ...
>     Kernel driver in use: atl1c
>
> by looking at the Realtek card, the PHY chip is the RTL8168B
> (single-chip Gigabit NIC Ethernet Controller for PCI Express)
>
> not sure if there is general knowledge of this Taiwanese NIC/Chip re:
> dropping packets or other performance issues? I note these boards are
> rev 1.0!!!!!
They are certainly not the greatest NICs in the world when it comes to
CPU efficiency, but I'm not aware of any specific prolems. Can you
actually just try with the atheros interface? That would rule them out
as possible source of problems.
>
> re: relatively high CPU for 8 cores running simple_ra - the '8' is
> actually only 4 real cores (2 logical cores per physical) but as can
> be seen from below,
> I don't believe I splashed out on a graphics card and just took the
> motherboard's capability. Perhaps my Scottish accent can be detected?
> Will look into getting something along those lines if it improves the
> graphics performance.
>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
> Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
> 00 [VGA controller])
> ..
>     Kernel driver in use: i915
That's an Intel HD 4000 or so, right? At any rate, they should have
enough horsepower to update a few plots via OpenGL. What indeed could be
happening is that hardware rendering is not used (the wx GUI toolkit
seems to be a little special sometimes, but then, who or what isn't?).
So two things:

1. could you share what "glxinfo | grep renderer" says? (or was it
glxinfo64? If both are present, send both :) )
2. there was a way to dis/enable wx OpenGL usage per config file. My
brain feels a bit holey these days; I'd have to research that.

General question: After things crashed, using the N210 works if you
re-start simple_ra (or any other UHD sample streaming program), or do
you need to power-cycle the N210?

Best regards,
Marcus