Gnu Radio apps freezes (locks up)

Rickard_R · November 26, 2012, 1:44pm

Even if I just run an example with UHD–>Null sink (that is without any
rendering GUI) I get the exact same problem that samples stop coming after a short
period of time.
Or if I just try to save the samples to a file it stalls/stops and I can only
save relative few samples.

I think what Patrik describes in his responses is probably a different issue
which I sometimes also have experienced, but relates to the GUI, not necessarily
the UHD communication.
In my case, the samples just stops coming from the device so I believe its UHD
related.

IMPORTANT NOTE: The green LED labeled C on the N210 goes from a steady ON (when
samples are delivered) to suddenly OFF at the instant when samples stop coming to
the host computer.
Also, the large orange LED goes from a steady ON when samples are streamed to
very rapidly blinking at the instant when samples stop coming.
Finally, not until I abort the stalled application the fast blinking orange LED
turns off completely again.

LED C means the DSP is in RX mode. If continuous streaming is on, 3
things can cause this light to shutoff:

a stop streaming command packet (from issue stream command)
overflow in the device. This never happens on the network devices
unless the sample rate is > 25e6 and the wire format is still sc16
ICMP destination unreachable packet. This usually comes when the
kernel sees that a destination socket is not open.

I think you can eliminate 1 and 2. Can you confirm 3 with a wireshark
run?

-josh

Rickard_R · November 28, 2012, 10:37am

On 27 nov 2012, at 07:13, Josh B. [email protected] wrote:

ports changing wildly back and forth on both the device and host, and

#define USRP2_UDP_UART_BASE_PORT 49170
#define USRP2_UDP_UART_GPS_PORT 49172

I guess this means several ports are active for different tasks.
But I see much more port numbers being used in my wireshark UHD log
files than these. Don’t know what that means.

Please find the transcript of the mentioned and seemingly crucial
packages from the beginning and the end when the UHD communication
fails. Note the selected packets’ numbering. The wireshark captured
the command: uhd_fft -a “addr=192.168.10.2, recv_frame_size=3008” -s
25e6

Is the behavior any different when the recv_frame_size is
unspecified/aka left default MTU?

Positive. Behavior is unfortonately exactly the same. Also independent
of the specific application.

The duration until “halt/stop” can vary quite inconsistently, i.e., with
large variations (sometimes immediately, sometimes several seconds or
more). Even tried to cool down device and laptop, but it had no effect.

MTU and frame sizes can have some effect of this, but it is still
extremely inconsistent (large variations). Its not like when I vary
these parameters (UDP frame & buffer size) and running the “iperf” tests
directly between the two laptops. Then its a very consistent behavior on
the performance, as described earlier.

Please find attached a complete summary of wireshark dump for
“benchmark_rate --sample_rate 25e6” with standard MTU size 1500,
unspecified recv_frame length, etc., (after a reboot).
Also the corresponding terminal input and output is attached.

In this run I notice the ports changed just after the packets became
small (see packet 2581–) so maybe the port switching was not itself the
cause for the UHD comm to fail ?!
Note that the small packets (number 2583 --) of around 66 bytes or so
keeps coming at a very reduced rate from the device (then with LED C
OFF, and orange LED fast blinking) until scripts ends after ~10 secs in
this case (or else after a “Ctrl-C” such as with uhd_fft).

Another question, what the app locks up, what makes it recover? Reload
app, power cycle user, replug eth cable, re ifconfig, restart PC?

Ctrl-C alternatively aborting/closing the window with GUI (“red
button”). Nothing else needed. All parameters stay put so its just to
launch again

Is it possible to determine what is causing the problem and what might
fix it?
Is it possible to determine whether it is device, uhd, or a host problem
(or a combination thereof) with any certainty ? I really want to use
full rx-rate !
Can I provide some other or more data to help track down the bug or
problem ?

Remark: I got reports others have similar problems also under Windows.
Tried myself under Windows 7 (same machine, dual boot) with the uhd
“benchmark_rate” and got very similar results. The Windows uhd binaries
was installed from the Ettus site. Since under Windows a different
Ethernet driver is used I thought its less likely a Ethernet driver
problem (also since it works with “iperf”). Hmmmmm.?!?!

-josh

Thanks a lot for all valuable support!!

/ Rickard