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

[Tom Rondeau]

On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech <address@hidden> wrote:
> On 09/03/2010 11:52 PM, Eric Blossom wrote:
> Thought about that, as well.  So replaced the graphical FFT sink with a
> file sink, and set the
>  "unbuffered" flag.  That file fills up in "fits and starts'--that is,
> it spends quite a while with
>  zero bytes in it, then really a lot of bytes, then no more bytes for
> quite some time, then
>  another lump of bytes, etc.  I confirmred that the "producer" end of
> the FIFO was producing
>  bytes at the correct rate.
>
> So when I'm sending "real" data to an actual USRP (f'rexample), the
> symbols will get clocked out at the right rate, provided
>  that I issue those bits in sufficiently large lumps to prevent the
> USRP from underrun on transmit.
>
> But what about situations where you might have a source of bits that's
> running in "real time" (like my little test case with the
>  external FIFO), and you'd like the resulting symbols to be "clocked
> out" at something resembling "real time"?  My test case
>  was just a test case, but I can certainly imagine situations where it
> actually matters.


Remember that GNU Radio runs stuff through each signal processing
block in "chunks." These chunk sizes can be around 100 to 32000 items
in size, more when there is time to spare and less when the system is
trying to operate quickly. When you're running with a sample rate of
4800, that's going to pass 4800 samples each second. At this rate, the
GNU Radio scheduler is likely using very large block sizes (you could
print out the value of noutput_items in one of the work functions to
see for sure). Let's say that, generally, each block is given an
noutput_items=8192. That's almost 2 seconds worth of data.

I just created a simple flowgraph in GRC with a noise source,
throttle, and scope sink. With varying rates on the throttle, you can
get see this happening. With such a simple flowgraph, the
noutput_items is always either 4095 or 4096, so it's pretty regular.
With a rate of 4800, you get a scope update about every second.

I've seen something like what you were observing with more complicated
flowgraphs with very small sample rates; when the scheduler doesn't
produce the same number of items each time through, it runs in "fits
and starts" as you said. Conversely, when running with a source like
the USRP, the USRP source is being run at a minimum of 250 ksps, so
the flow graph has to work to keep up with that and therefore runs
data through the whole graph "faster" but only because the sinks are
being updated with new data more quickly.

Like Eric said, remove the throttle or at least change the rate and
that should clean things up.

Tom