discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes (locks up)


From: Rickard
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes (locks up)
Date: Tue, 27 Nov 2012 17:31:57 +0100

On 27 nov 2012, at 07:13, Josh Blum <address@hidden> wrote:

> 
>> I have now played with the wireshark.
>> 
>> I do not get what you suggest "ICMP destination unreachable packet"
>> or something similar. The only "ICMP" protocol related is when I
>> connect the device and setting up the ip address, but no "unreachable
>> packets" or similar during the uhd run. When running there are only
>> UDP frames/protocol.
>> 
>> Instead, however, I discovered some really suspect behavior with the
>> ports changing wildly back and forth on both the device and host, and
>> UDP packet/frame size then change much too. This happens both in the
>> beginning of the streaming (see attached packets 241--287), then
>> after a while it settles to the requested (constant) packet size
>> (3050 bytes, close to the requested 3008 bytes) and the ports becomes
>> fixed (see packets 1271-1277) .
>> 
>> But then in the end, when it all fails, the ports on the device and
>> host suddenly change again and the packets becomes very small, like
>> 58 or 60 bytes only (see packets 211078 --). The little actual data
>> in those failing packets seem quite odd too.
>> 
> 
> The packets in the dump all look quite normal. If it helps, here is the
> mapping for the ports from fw_common.h
> 
> #define USRP2_UDP_CTRL_PORT 49152
> //#define USRP2_UDP_UPDATE_PORT 49154
> #define USRP2_UDP_RX_DSP0_PORT 49156
> #define USRP2_UDP_TX_DSP0_PORT 49157
> #define USRP2_UDP_RX_DSP1_PORT 49158
> #define USRP2_UDP_FIFO_CRTL_PORT 49159
> #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

Attachment: terminal_output_benchmark_rate_--rx_rate_25e6.txt
Description: Text document

Attachment: eth0_uhd_dump_benchmark_rate_--rx_rate_25e6.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]