Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"

[Marcus D. Leech]

On 09/06/2010 05:03 PM, Tom Rondeau wrote:
> On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom <address@hidden> 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