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 <wu.t...@comf5.comm.eng.osaka-u.ac.jp>: >> 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 <wu.t...@comf5.comm.eng.osaka-u.ac.jp> >>> >>>> 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 >>> >> >> > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
