discuss-gnuradio
[Top][All Lists]
Advanced

[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

Attachment: pgpm_L9z9KQP8.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]