--- On Fri, 4/13/12, Martin Braun <martin.br...@kit.edu> wrote:
> From: Martin Braun <martin.br...@kit.edu> > Subject: Re: [Discuss-gnuradio] Data lost whe using big file sources > To: discuss-gnuradio@gnu.org > Date: Friday, April 13, 2012, 10:38 AM > On Thu, Apr 12, 2012 at 11:14:37PM > -0700, Bogdan Diaconescu wrote: > > Ok, I got no so many replyies to this post and I > thought I should present what I investigated so far. > > > > I tried to trace the root of the problem and firstly I > simplified the use case by filling the source files with > just the same value (arbitrarily 0x18) and looking for > different values into > gnuradio-core/src/lib/runtime/gr_block_executor.cc:gr_block_executor::run_one_iteration() > that is in the loop for the TPB. > > > > One note, if I change the TPB to Single Threaded > Schedulrer the problem is gone but the point is to use one > thread for each block. > > This is also what I have observed in the past. > > > Looking for an error in the run_one_iteration() I see > that the output of the file sinks is not corrupted, the > corruption appears only in run_one_iteration() for the block > I'm using, specifically d->input(i) has at a moment a > corrupted value. > > > > Speaking about corrupted value, the corruption I see is > actually a zero value instead of expected data (0x18) but > the funny thing is that if I print the value twice, on > second print the value is the correct 0x18 (I guess here > Heisenberg principle has it's part here :) ) > > > > From where the d->input(i) comes from? It is > gr_block_detail that gets set-up when connecting blocks each > other. This is probably next step to investigate. > > > > The results so far: moslty learning gnuradio internals, > problem is still hidden. > > Bogdan, > > can you cook up a test case that (sometimes) fails the way > you describe > and upload it somewhere? I'd love to join the hunt. > My initial guess to this problem was that the TPB scheduler > is the > source of the randomness and some race conditions which only > appear when > the flow graph is running at infinity clock rate are the > actual bug. I > was really hoping the file source was to blame, would have > been much > easier to debug. > > MB Hi Martin, sure, I will craft a small example when I'll get at my development machine. Although the test case is quite simple: 1. generate 6 big files (I'm using now 800MB each file just to get more errors) filled with the same value, e.g. 0x25 2. modify an existing gr_block based block to support 6 file sources (I guess 6 is not important, it could be more or less) 3. modify forecast() function to return 1:1 for each input 4. modify general_work() to test each byte in the 6 inputs against the 0x25 value. If different this is the error. 5. connect the file sources to the module in python and run That is for short. Thanks and keep in touch Bogdan > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > -----Inline Attachment Follows----- > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
