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

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 <246tnt@gmail.com> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio