[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Data lost whe using big file sources
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] Data lost whe using big file sources |
Date: |
Fri, 13 Apr 2012 09:38:50 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
--
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
pgpm_L9z9KQP8.pgp
Description: PGP signature