On Fri, Apr 25, 2014 at 7:06 PM, Bolin Hsu <[email protected]> wrote:
> 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. > If you aren't disconnection/reconnecting blocks in a flowgraph, there is no need to lock and unlock the flowgraph. Tom > (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 > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
