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
