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 <246...@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
