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

[Andrew Davis]

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
>>
>
>