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

[John Malsbury]

Sounds dangerous if you also happen to have very high throughput applications to run?  Am I wrong?

On Fri, Oct 10, 2014 at 5:59 PM, Ed Criscuolo <address@hidden> wrote:

Yep, that was me.  I was getting to pipe-in with the same suggestion.

@(^.^)@  Ed

On 10/10/14 8:20 PM, Vanush Vaswani wrote:

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

_______________________________________________
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