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

[Feng Andrew Ge]

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