discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Strange output of "0" at the terminal


From: Wu Ting
Subject: Re: [Discuss-gnuradio] Strange output of "0" at the terminal
Date: Sat, 25 Feb 2012 00:22:27 +0900 (JST)
User-agent: SquirrelMail/1.4.8

Hi! Thank you for your suggestions!

I realized it is a problem related with computer speed. Today I used a
laptop to run the same code, and 'O' is printed much more frequently.

However, the computer I'm using is a quite good one. It has intel i7
3.4GHz 8-core, and when the code is running, CPU is only used by about
10%, and memory is also used by no more than 15%. On the other hand, I
also checked number of messages in message queue, and I've found that when
'O' is printed, sometimes there are only several messages in the queue. So
I don't understand why it has this outflow problem.

And is it possible to catch this error when it happens, so that I can deal
with it in the problem?

Thanks!

Wu

> 2012/2/23 Wu Ting <address@hidden>
>
>> Hi! Thank you for your response. I've kept working on this problem for
>> two
>> days, but still cannot find a way to solve it.
>>
>> I simplified the program and have determined that the 'O' is produced is
>> this while loop:
>>
>> while msgCount<10000:
>>    msg = tb.queue.delete_head()
>>    payload = msg.to_string()
>>    f.write(payload)
>>    msgCount += 1
>>
>> I also tried to make it sleep for a short time after each operation:
>>
>> while msgCount<10000:
>>    msg = tb.queue.delete_head()
>>    sleep(0.00001)
>>    payload = msg.to_string()
>>    sleep(0.00001)
>>    f.write(payload)
>>    sleep(0.00001)
>>    msgCount += 1
>>
>
> Two quick things. First, the tb.queue.delete_head() is a blocking call, so
> it will wait until there is a message to process. You don't need to sleep.
> Adding a sleep call here is probably only making things worse since you're
> already not keeping up with the samples. Second, the sleep() call is
> generally only accurate to about ~10 ms, but you're asking it to sleep for
> 10 us. I'm not sure if it rounds up or down. Worse case, you're making the
> loop sleep for about 30 ms total; best case is you actually aren't pausing
> at all.
>
> Tom
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]