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

[Bolin Hsu]

I found pausing the flow graph to be the wrong action for my situation.

I tried to find out how many samples are in my flow graph. I inserted logging to the work function of two blocks in my flow graph. One is the signal source whose frequency is altered if a frequency shift is detected. The other is the last block of my flow graph. The log prints the value of nitems_written() of the blocks. The difference of the items written between these two blocks is roughly equal to the samples I lost waiting for the new setting to take effect. So I think the latency is the time it takes to drain the samples that has gone too far down the flow graph to be affected by the new setting.

Obviously pausing the flow graph won't help. Instead, it would be helpful if I could speed up draining the samples that can't be affected by the new setting, something like flowgraph.clear_downstream(basic_block_sptr start_block), which discards all samples in blocks that is reachable from start_block's output ports according to the flow graph. The time spent on moving and processing useless samples could be saved. Does this idea make sense?

Thanks,

Bolin

On Wed, Apr 23, 2014 at 5:11 PM, Bolin Hsu <address@hidden> wrote:

I wish to report my findings on the idea of pausing the flow graph, and hope to get feedback from the experts on this list. I only started using GNU radio last month so it is likely I didn't have enough experience to understand it properly. 

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

I looked into the scheduler source code to find ways of implementing pause and resume. It seems very hard to pass the intention to pause or resume to the scheduler. Specifically, top_block_impl creates a scheduler_tpb, and scheduler_tpb creates a thread using the functor thread_body_wrapper. The thread_body_wrapper contains another functor tpb_container. In tpb_container's () operator, a tpb_thread_body is constructed. So the way scheduler_tpb runs a block is by creating a thread that runs the constructor of tpb_thread_body through two levels of functors. The tpb_thread_body constructor contains an infinite loop. In every iteration of the loop, the work function of the block running on the thread is called if permissible. So tpb_thread_body seems to be a good place to pause the flow graph, and I need to send the intention to pause or resume to tpb_thread_body. The intention can easily go from python to top_block to top_block_impl to scheduler_tpb. But the tpb_thread_body is created by the thread library and not readily accessible by scheduler_tpb. Furthermore, there are two level functor indirection between scheduler_tpb and tpb_thread_body. 

I did find two existing ways of passing information to tpb_thread_body: thread interrupt and message passing. But they don't seem to be the proper ways of sending the pause and resume information.

Any suggestion is welcomed.

Thanks,

Bolin

On Wed, Apr 23, 2014 at 8:22 AM, Bolin Hsu <address@hidden> wrote:

Hi Marcus,

Thanks for reply. Let me try to answer the questions.

Yes. The signal frequency shifted by +/- 5%. 

The transfer burst is constant.

The frequency shift remains constant during a burst. So I estimate the shift in the beginning of a burst, and fix the setting of demodulator and resampler over the whole burst. I use FFT and interpolation to estimate the frequency shift. 

The "estimate frequency shift then configure demodulator" approach works, except it takes 600-700 ms for the demodulator to start outputting meaning data after receiving correct configuration. I call this 600-700ms time the reconfiguration latency. 

Maybe I used wrong term. By reconfiguration I mean I made two function calls: one is the set_frequency of signal source, the other is set_resamp_ratio of the fractional resampler. My data rate is 44.1k. So I lost about 30k samples when I was waiting for the reconfiguration to take effect.

Regards,

Bolin