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 >> listDiscuss-gnuradio@gnu.orghttps://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
