|
From: | Feng Andrew Ge |
Subject: | [Discuss-gnuradio] uhd_usrp_sink often blocks in non-continuous data sending |
Date: | Thu, 03 Mar 2011 18:36:16 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 |
Josh, I have observed uhd_usrp_sink quite often blocks when working in non-continuous scenarios. Here is one example, node 192.168.200.2 (A) pings 192.168.200.1 (B), one result (on node A) is here: ping 192.168.200.1 -i 0.5 PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data. 64 bytes from 192.168.200.1: icmp_req=1 ttl=64 time=7.65 ms 64 bytes from 192.168.200.1: icmp_req=2 ttl=64 time=507 ms 64 bytes from 192.168.200.1: icmp_req=3 ttl=64 time=1008 ms 64 bytes from 192.168.200.1: icmp_req=4 ttl=64 time=1507 ms I have checked the ICMP message on node 192.168.200.1 (B) as below: 1st ICMP message on node B: Rx: ok = True len(payload) = 98, time 1299191494.231131 Tx: len(payload) = 98, time 1299191494.231269 2nd ICMP message on node B: Rx: ok = True len(payload) = 98, time 1299191494.732206 Tx: len(payload) = 98, time 1299191495.231755 For the first ICMP message, node B responds within 138 micro-seconds; however, it holds the second ICMP message for up to 500ms. Notice that after 500ms, Node A sends its third ICMP message. So I think the following ICMP message's arrival triggers Node B's response. Since uhd_USRP_sink's WORK function uses SEND_MODE_FULL_BUFF and its timeout is 1.0 second, uhd_USRP_sink blocks when not enough samples are available. Corresponding to the above behavior, for the second ICMP message (which in total has <98+19>*16 = 1972 samples using GMSK, 2sps), either its entire sample stream or part of the sample stream is held. The printout of noutput_items is always same as the real num_sent. I am not sure how do you handle the blocking. Further, it seems that GNU Radio scheduler might give uhd_usrp_sink's WORK function an noutput_items which is larger than what's really available from the previous signal processing block. As such, do you know an approach to solve this blocking problem? I have tried to set the timeout as a small value, e.g. 1ms, but it seems not able to completely solve the problem. I have never seen such behavior using the raw Ethernet code. What's the difference? Andrew |
[Prev in Thread] | Current Thread | [Next in Thread] |