Try decreasing the buffer size in gnuradio-runtime/lib/flat_flowgraph.cc I use: #define GR_FIXED_BUFFER_SIZE 2048
On Fri, Apr 25, 2014 at 9:08 AM, Bolin Hsu <[email protected]> wrote: > 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 <[email protected]> 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 >> functorthread_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 <[email protected]> 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 >>> >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
