I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in flat_flowgraph.cc. This is regarded as a dodgy hack by all the GR developers here, but it worked for me (and I read the article on latency). I believe the guy who wrote GMSKSpacecraftGroundstation had the same problem, and found it in one of his old threads.
On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob <dan.caja...@gmail.com> wrote: > Hey John, > > I am way out of my depth here, but while working on a custom python block > the other day, I saw some weird behavior in 3.7.5 that was similar. Setting > the global max output had no effect, but setting the just-upstream block(s) > min/max output buffer size(s) low fixed my apparent slowliness. > > Very Respectfully, > > Dan CaJacob > > On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury > <jmalsbury.perso...@gmail.com> wrote: >> >> Default scheduler. >> >> tb.start(1024), with different values, etc, etc. >> >> Most of the downstream blocks are stock GNU Radio blocks - a delay block >> (max delay is 1 sample), logical operators, etc. I guess I'll add some >> printf debugging? >> >> -John >> >> >> >> >> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller <marcus.muel...@ettus.com> >> wrote: >>> >>> Hi John, >>> On 10.10.2014 19:33, John Malsbury wrote: >>> >>> Toward the end of the receive chain, there are a multitude of blocks that >>> are used for Viterbi node synchronization. I've found that the number of >>> blocks in series (3-5), combined with the low datarates at this point in >>> the flowgraph, lead to latencies on the order of 1-2 minutes. That is to >>> say, once the node synchronization is accomplished, it takes 1-2 minutes >>> to >>> flush these blocks and get the fresh, good data through. This is >>> measured >>> with function probes on the state of the sync process, and BERT analysis >>> of >>> the demodulator output [through TCP/IP socket]. >>> >>> I see you found the hidden interplanetary signal delay simulator. >>> Congrats! Watch out for the red shift in downstream samples. >>> >>> No, seriously, that sounds like a lot. >>> You are using 3.6.4.1 with the default scheduler, tpb? >>> >>> - I've tried messing around with the output buffer size option in the >>> flowgraph, but this seems l to have a negligible impact. >>> >>> That surprises me. How did you mess around? top_block->run(1024)? >>> Do your blocks really get called with smaller input item sizes? (do a >>> little printf-debugging) >>> >>> - I can write some custom blocks to reduce the overall block count, >>> but >>> I have demonstrated that this provides a linear improvement, rather >>> than >>> the two-order-magnitude improvement I need. >>> >>> Any general advice anyone can offer? It feels like the right solution is >>> to force small buffer sizes on the relevant blocks... >>> >>> agreed. But still. That sounds *bad*. Are you sure none of the block >>> demands a large input/output multiple? >>> >>> >>> Greetings, >>> Marcus >>> >>> -John >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
