|
From: | Feng Andrew Ge |
Subject: | [Discuss-gnuradio] Re: uhd_usrp_sink often blocks in non-continuous data sending |
Date: | Fri, 04 Mar 2011 11:12:28 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 |
Josh,Thanks for pointing out the time function library, which I actually intended to call for printout analysis. As shown below, the huge delay was not caused by the WORK function's SEND. I am still trying to figure out the root, will let you know once I have it.
Andrew SEND: 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.34 ms 64 bytes from 192.168.200.1: icmp_req=2 ttl=64 time=507 ms ^C --- 192.168.200.1 ping statistics --- 4 packets transmitted, 2 received, 50% packet loss, time 1515ms rtt min/avg/max/mdev = 7.340/257.186/507.033/249.847 ms, pipe 2 RECV Rx: ok = True len(payload) = 98, time 1299249666.140256 Tx: len(payload) = 98, time 1299249666.140396 gr_uhd_usrp_sink::work() 1920 time before send() 1341920.684302 time after send() 1341920.684409 Rx: ok = True len(payload) = 98, time 1299249666.641308 Tx: len(payload) = 98, time 1299249667.140895 gr_uhd_usrp_sink::work() 1920 time before send() 1341930.684843 time after send() 1341930.684949 Rx: ok = False len(payload) = 98, time 1299249667.148811 Rx: ok = True len(payload) = 98, time 1299249667.656015 Tx: len(payload) = 98, time 1299249668.141481 gr_uhd_usrp_sink::work() 1920 time before send() 1341940.685471 time after send() 1341940.685581 On 03/04/2011 12:19 AM, Josh Blum wrote:
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, The uhd_usrp_sink::work() should always block until the entire buffer has been transmitted. There is no choice in the matter. However many samples gnuradio buffered before calling work(), we must send all of those samples. Now, there is a question of where is the delay, what is taking too long, what is buffering too much, etc. I am attaching a diff with prints for the time before and after the send() call in the work function. This will tell us how often work is called, how many samples are transmitted, and how long this operation takes. Please try the attached diff and post the output. Thanks, -Josh
[Prev in Thread] | Current Thread | [Next in Thread] |