[Discuss-gnuradio] Fw: Re: Data lost whe using big file sources

[Bogdan Diaconescu]

I now realize that I didn't sent the testcase to the list. Sending this to the 
whole list now.

Thanks,
Bogdan

--- On Sat, 4/14/12, Bogdan Diaconescu <address@hidden> wrote:

> From: Bogdan Diaconescu <address@hidden>
> Subject: Re: [Discuss-gnuradio] Data lost whe using big file sources
> To: "Martin Braun" <address@hidden>
> Date: Saturday, April 14, 2012, 2:21 AM
> Hi Martin,
> 
> attached is a gr block that reproduces the problem. In the
> python directory you'll find a generate directory where is
> an executable that will generate the files in out
> directory.
> 
> ./test.py will run the test
> 
> I realize though that the style of the block is old compared
> to what is now in the gnuradio.
> 
> Let me know if you can reproduce the problem on your side.
> 
> Thanks,
> Bogdan
> 
> --- On Fri, 4/13/12, Bogdan Diaconescu <address@hidden>
> wrote:
> 
> > From: Bogdan Diaconescu <address@hidden>
> > Subject: Re: [Discuss-gnuradio] Data lost whe using big
> file sources
> > To: address@hidden,
> "Martin Braun" <address@hidden>
> > Date: Friday, April 13, 2012, 2:27 PM
> > 
> > 
> > --- On Fri, 4/13/12, Martin Braun <address@hidden>
> > wrote:
> > 
> > > From: Martin Braun <address@hidden>
> > > Subject: Re: [Discuss-gnuradio] Data lost whe
> using big
> > file sources
> > > To: address@hidden
> > > 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
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >

ccr-receiver.tgz
Description: application/compressed-tar