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) <muel...@kit.edu> 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 <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
testindeterminate.grc
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
