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
