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 < reiichiro.s.nak...@gmail.com> 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) <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
