[USRP-users] Timeout while streaming error while implementing receiving samples in different thread

Marcus Müller marcus.mueller at ettus.com
Thu Apr 30 03:06:47 EDT 2015


Hi Kamal,

ah, ok!
My suspicion stays that at the time you call recv() you haven't
effectively made the device stream samples, and somehow don't do that --
thus, recv() waits for longer than the timeout, and you get this error
message.
Thus, a few comments on your reply:
>
> 1.) We have n't set any value in the constructor of time_spec_t for
> steam_cmd. it is un-disturbed.
hm. ok, so this then means that you really don't issue your stream_cmd
long enough before the first call to recv(); you can try increasing
recv()'s timeout value only for the first call!
>
> 2.) I am using a Highend system for executing the code ( Lenovo Y510P
> ), So system resources should n't be any problem. No, We are unable to
> receive any samples, What we get is a
>
>         /Timeout while streaming/
>
>
Again, this is not about system performance, probably, but about some
logical error in your application -- you call recv() before there is
something to receive!
>
> 3.) yeah, the timeout might not be sufficient. If it is so, why would
> it take so much time, to push samples to PC...?? does timeout really
> varies from experiment to experiment..??
3s is not a network/USB latency you'll ever see. Something is broken
with your application logic.
>
> This is the stream_cmd_t we are using for our test,
>
> /uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>  ..../
>
> and --nsamps to nothing, So it should start with continuous mode. NO
> room for  TIME_SPECT_T() issue :) :) .
So /when/ do you /issue/ that command? (By the way, you *do* touch the
timespec in the stream_cmd, but it doesn't matter, with stream_now, and
a time_spec_t(0)).

Regarding the rest of your approaches: this looks like you're guessing;
it's happened to me many times, and it seldom brings you to the right
solution, so
> 1.) Is the /const buffer reference/, semantics used for first argument
> passed to recv() command is causing problem from storing samples from
> board..??
No.
> 2.) Since we got into multi threading, should we need to really take
> care about uhd::set_thread_priority( priority_value, real_time) in
> each thread function..??
Not really.
> 3.) we are using new c++11 standards for creating and managing
> threads. Is this causing problem..??
Not probable.
>
> 4.) passing parameter values to DataAcquisitionThread, is causing
> problem..??
I don't know your application, but if you didn't make a mistake, why
should it?

Best regards,
Marcus


On 04/30/2015 08:34 AM, kamal kumar jeldi via USRP-users wrote:
> Hi Marcus,
>
> Once again thanks for your kind/patient reply, Since the reply is
> huge, it took me time to reply to each suggestion you answered.
>
>
> I am not using any other third party library ( like threading building
> blocks, tbb) for concurrent queue. with some knowledge from books and
> online sources we have coded our own, here is the implementation ( if
> it might helps for other trying the same threading problem ) code
> pasted in pastebin.
>
> pastebin link : /http://pastebin.com/H0yqkfgB/
>
> In the above code, I have removed all template classes and hard coded
> it for type 'double'. It worked perfectly in normal compilation: /g++
> -std=c++11 source.cpp -o exec -lpthread
> /
> So, from the above code and mail body with sub: "setting thread
> priority during multi threading", you might have understood that, the
> problem is from UHD ( ERROR_CODE_TIMEOUT) itself.
>
>
> Are you suggesting me to test by altering the time_out parameter in
> recv() ?, To exactly find out where the Timeout While streaming is
> coming..??
>
> 1.) We have n't set any value in the constructor of time_spec_t for
> steam_cmd. it is un-disturbed.
>
> 2.) I am using a Highend system for executing the code ( Lenovo Y510P
> ), So system resources should n't be any problem. No, We are unable to
> receive any samples, What we get is a
>
>         /Timeout while streaming/
>
> We have tried by placing small stubs before and after recv() command,
>
> 3.) yeah, the timeout might not be sufficient. If it is so, why would
> it take so much time, to push samples to PC...?? does timeout really
> varies from experiment to experiment..??
>
> This is the stream_cmd_t we are using for our test,
>
> /uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>         uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>         uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>     );
>     stream_cmd.num_samps = num_requested_samples;
>     stream_cmd.stream_now = true;
>     stream_cmd.time_spec = uhd::time_spec_t(); /
>
>
> and --nsamps to nothing, So it should start with continuous mode. NO
> room for  TIME_SPECT_T() issue :) :) .
>
>
> Thank you for this great tip regarding memory management while
> allocating memory space with new ( The best part of your reply) .
> Yeah, will work on deleting the allocated memory locations dynamically.
>
> We people have got some queries regarding the problem, We came up with
> some conclusions why this problem occurred,
>
> 1.) Is the /const buffer reference/, semantics used for first argument
> passed to recv() command is causing problem from storing samples from
> board..?? if it is so, what would you suggest me, for storing
> different memory locations address in the queue..??
>
> 2.) Since we got into multi threading, should we need to really take
> care about uhd::set_thread_priority( priority_value, real_time) in
> each thread function..??( this is why we thought of throwing a mail
> with different subject), if it is so, what is the necessary care
> should I need to take for multi threading.
>
> 3.) we are using new c++11 standards for creating and managing
> threads. Is this causing problem..??
>
> 4.) passing parameter values to DataAcquisitionThread, is causing
> problem..??
>
> Now you might be knowing that we are not working with any third party
> threading libraries, Please help us in that way.
>
> Thanks in advance,
>
> Hoping for a solution,
> Kamal Kumar Jeldi
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150430/854dff13/attachment-0002.html>


More information about the USRP-users mailing list