discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio


From: Reiichiro Nakano
Subject: Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio
Date: Wed, 3 Oct 2018 13:55:46 +0900

Here's an updated flowgraph where you don't need a separate file source. Just run the flowgraph twice for a few seconds each. You'll likely get different file sizes but `cmp` doesn't care, it'll still show the first differing byte which should still prove the bug exists.

On Wed, Oct 3, 2018 at 1:51 PM Reiichiro Nakano <address@hidden> wrote:
I'm not using those deprecated blocks.

Anyway, I dug deeper and found the block that was causing the indeterminate behavior. It is the complex "Divide" block! Here's a minimum reproducible flowgraph. You'll have to adjust the file source to use some IQ stream you may have lying around. Sorry about that, I couldn't see a GNU Radio block for a complex source which you could set to output a fixed number of samples. The input file will probably have to be a few 10s of MBs for you to catch it since the indeterminism happens pretty randomly, some at byte 10M and some at byte 2K.

To run the experiment just run the flowgraph twice (setting the file sink to different paths each time) then diff the two output files via `cmp out1.bin out2.bin -b`. You should get an output like `out1.bin out2.bin differ: byte 1883929, line 6715 is  12 ^J 260 M-0`. Oh and the weird thing is the value of the differing bytes are always 12 and something else.

On Wed, Oct 3, 2018 at 1:24 AM Müller, Marcus (CEL) <address@hidden> wrote:
Are you perchance using the modulator and demodulator blocks from the
"Deprecated" category?

Best regards,
Marcus

On Tue, 2018-10-02 at 19:34 +0900, Reiichiro Nakano wrote:
> Interesting. Thanks for the response. I also have a bunch of message passing going on. Do you think it could be dropped messages? I seem to remember reading that PMT ports aren't back pressured like the streaming ports. What happens when a queue fills up and the block can't catch up?
>
> Anyway, what I would also like to know is a bit more explanation for the last message in the thread I linked to in my first email. It seems like this was a known problem with large data files and the absence of a throttle block?
>
> On Tue, Oct 2, 2018, 7:25 PM Sylvain Munaut <address@hidden> wrote:
> > Hi,
> >
> > > Unfortunately, there were no further replies to that thread but I did see that my same question "pops up every once in a while". Anyway, my specific problem is I'm trying to QPSK demodulate + RS decode a 2MS/s, 1Mbps bit rate, 10GB IQ file. This works fine, but I'm getting a different number of successfully decoded packets every run. I am using a throttle block, and in fact tried to reduce the throttling rate to 200KHz (samplingrate/10), but it still doesn't seem to work. As for how much CPU my flowgraph is utilizing, it takes up around 80% of all 8 of my CPU cores at the regular sampling rate, while taking around 30% of my cores at samplingrate/10. Do you guys have any idea on what might be going on? The thread I'm referencing is from 2013, but is it still relevant? Any technical reasons for the non-deterministic behavior? I'm using 3.7.13.2.
> >
> > Depends on your flow graph obviously, but in general, no.
> >
> > Unless for the obviously "random" blocks (like noise generators and
> > such), AFAIK most other blocks should have a deterministic behavior
> > (at least when running on the same exact GR version). Usually
> > undeterministic behavior points to a bug in one of the blocks that
> > doesn't properly deal with the boundaries in the work() call.
> >
> > cheers,
> >
> >    Sylvain
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: testindeterminate.grc
Description: Binary data


reply via email to

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