Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Vanush Vaswani]

I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is regarded as a dodgy hack by all the GR developers here, but it
worked for me (and I read the article on latency). I believe the guy
who wrote GMSKSpacecraftGroundstation had the same problem, and found
it in one of his old threads.

On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob <address@hidden> wrote:
> 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
> <address@hidden> 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 <address@hidden>
>> 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 list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>