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

[Wu Ting]

I tried the code without write(), and it still has the problem. But it
seems to be less frequent. I will try your method. Thank you!

> You are writing to a file in a blocking thread, its not the CPU it's
> the hard drive. You should try the program without the write. Then if
> it is the problem you should write out to a file on a ram disk then
> save it to a real disk later.
>
> 2012/2/24 Wu Ting <address@hidden>:
>> 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
>>>
>>
>>
>