[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
Date: Mon, 06 Sep 2010 20:51:17 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]