Re: [Discuss-gnuradio] How to reduce reconfiguration latency

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Bolin,

my compliments for being this investigative on your issue!

> My understanding of the flow graph execution was a scheduler checks
> the blocks in a round robin fashion, and execute the work function
> of a
block
> if the block can make progress.

Not really. As you notice further on, the scheduler is called "tpb",
which stands for "thread per block".
What happens is that every block is executed in its own thread, which
sleeps until one of the neighbor blocks notices the scheduler that he
has done some work and the scheduler notfies the block thread that it
can continue.

> So my intention was to add functions to the scheduler to allow
> pause and resume from python via top block. When
paused,
> the scheduler won't run any block's work function.

Interesting, yet I don't understand why you would want to do that. How
does that paused time help you reduce your latency?
If I understood you correctly, the number of samples until your
frequency offset estimator has come to an estimate plus the number of
samples that are already in the pipeline between that estimator and
the frequency correction is very large (44.1kHz*0.6s =~ 30,000). I
still blame that on the estimator ;) and I don't think you can solve
that "information theory sampling time" latency issue by stopping
"reality processing time"...

You can try to reduce the number of samples that are being worked on
each time (set_max_noutput_items) or even limit the maximum buffer
size between two blocks (set_max_output_buffer_size), which both might
hurt you. Please have a look at
http://gnuradio.org/doc/doxygen/index.html#latency .

Anyway, have you had a look at gr::top_block::lock()? It's meant to
stop the flowgraph prior to reconfiguration (which in "official" GR
lingo means you dis- and reconnect some blocks). I think there was a
discussion yesterday about if that empties buffers, and I think it
doesn't touch buffers of connections you don't change. I'm not quite
sure about that, though.

Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWMPTAAoJEBQ6EdjyzlHtoqcH/RzAKsfHAL2adT4D1rsof9G3
11XrkUL0//yCopT+7zawKnUKtUNJJ+6/Eu3DG23mWR/irqTYBCPbM/CTOsS6m7bz
ZlRFBtHJslNLk0426QPA7IOisvy1O23ESk4eR5enxDRfHlp5K6cMXYRDuOZ8k9hi
Ur7oQUmwKQSP9NObidc0odnDRfz9lkS1RWW+n4sSX3hA3tFpkrJnlrGyW/dQ9Awp
SUBHhreS+skXSXvYAMwB0U6eWLKk0+EQEeec5R6zqQ2tuBO5UcoXE2OJuGYPWaJt
EVoB4ZuKOgIntjPiRMNV7xus2hyu5eBzxvQoY7W0E9RGXBcxRp4nWH0jjjpbhYA=
=ZzcD
-----END PGP SIGNATURE-----