|Subject:||Re: [Discuss-gnuradio] High Flowgraph Latency in 126.96.36.199|
|Date:||Fri, 10 Oct 2014 20:07:43 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0|
On 10.10.2014 19:33, John Malsbury wrote:
I see you found the hidden interplanetary signal delay simulator. Congrats! Watch out for the red shift in downstream samples.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].
No, seriously, that sounds like a lot.
You are using 188.8.131.52 with the default scheduler, tpb?
That surprises me. How did you mess around? top_block->run(1024)?- I've tried messing around with the output buffer size option in the flowgraph, but this seems l to have a negligible impact.
Do your blocks really get called with smaller input item sizes? (do a little printf-debugging)
agreed. But still. That sounds *bad*. Are you sure none of the block demands a large input/output multiple?- 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...
|[Prev in Thread]||Current Thread||[Next in Thread]|