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

[Reiichiro Nakano]

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