On 09/06/2010 05:03 PM, Tom Rondeau wrote: > On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom <e...@comsec.com> wrote: > Marcus, > Indeed, this could be something we want to talk more about. Kind of on > the periphery of my vision, I can see a handful of applications where > the large chunking issue could be a problem. If we can define enough > need, then we can talk more about finding the right way about it. > > Eric's suggestion is a good start. Tell it how many items you want and > then run the loop based off that number or the noutput_items, > whichever is smaller. If this works well for you, we might want to > find a way of integrating that concept as part of the > scheduler/basic_block. > > Well, like I said, we can think this through more clearly if you come > up with positive results with that hack. > > Tom > > I hacked in a hard-coded value as a temporary test that amounts to 100msec worth of "super symbols" (the actual symbols are di-bits, at a nominal 4800symbol/sec rate, but I send 1200 packed bytes/second over the FIFO) from my external source.
Looking at the debug logging setup by the scheduler, the scheduler has asked for 32767 noutput_items on the gr.file_source() in my flow-graph, and I'm returning 100msec worth (which is 120 items in my case). The result is a flow-graph that runs with much less apparent latency, depending on what blocks I pick. If I put in an interpolator block as the last item in the graph before the FFT display, it becomes "chunky" again, so I put in a rational resampler to resample up to the final channel bandwidth (mininum 500KHz for a USRP2, if I've done my math correctly :-) ). But the result is quite a bit more CPU hungry than the previous "fits and starts" version of the flow-graph. So this little hack is instructive, but not in and of itself any kind of path forward. It seems like some kind of global approach to the latency issue for narrow-bandwidth/low-event-rate applications is definitely worth discussing. Likely much careful treading required :-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
