[Discuss-gnuradio] uhd_usrp_sink often blocks in non-continuous data sending

[Feng Andrew Ge]

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