Thanks for suggestions of Vanush, Marcus, and Tom. I am happy to report that I was able to reduced the wasted samples from about 30k to about 1.5k.
Here's what I tried: (1) #define GR_FIXED_BUFFER_SIZE 2048 in flat_flowgraph.cc. This gave me the result reported above. The down side of this approach is I needed to re-build and re-install GNU radio. What about some hook to set this at start up time? (2) Set max_noutput_items by tp.run(2048). The latency stayed about the same. So limiting the number of output items alone isn't enough to reduce the number of samples in the flow graph. (3) tp.lock() and tp.unlock(). My application stopped working after I made these calls because the time it took to unlock the flow graph is longer than transferring the burst of data. I only changed the frequency of a signal source and interpolation ratio of a resampler. I didn't make any disconnection or connection. From the log, it seems the whole flow graph was restart. There was ~5 second blank without any log before the flow graph starts to run again, and the signal source's nitems_written() starts from 0 again after the 5 seconds blank. So I suspect the samples in some blocks were lost during unlock. Anyway, the 5 second restart time means this is not the right solution to my problem. (4) block.set_max_output_buffer(). I tried to set this value to a couple of the blocks, and found it not sufficient to reduce the number of wasted samples. There are too many blocks in my flow graph to set them all, and maintaining them might be a problem. So I decided to abandon this approach. Thanks, Bolin On Fri, Apr 25, 2014 at 6:53 AM, Tom Rondeau <[email protected]> wrote: > On Thu, Apr 24, 2014 at 10:14 PM, Vanush Vaswani <[email protected]> wrote: > >> Try decreasing the buffer size in gnuradio-runtime/lib/flat_flowgraph.cc >> I use: >> #define GR_FIXED_BUFFER_SIZE 2048 >> > > There are a number of hooks to each block to set various values to help > you control stuff, like set_max_output_buffer. See the docs for more: > > http://gnuradio.org/doc/doxygen/classgr_1_1block.html > > Just be careful using these! They are advanced functions since you're > messing with the scheduler behavior. > > Tom > > > > >> 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 >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
