[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] High Flowgraph Latency in

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] High Flowgraph Latency in
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

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 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?



Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]