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

[Eric Blossom]

On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote:
> On 09/04/2010 08:08 PM, Tom Rondeau wrote:
> > On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech <address@hidden> wrote
> >   
> > Like Eric said, remove the throttle or at least change the rate and
> > that should clean things up.
> >
> > Tom
> >
> >   
> I also noted in the reply to Eric that I observe the same behaviour with
> an external source that is producing 4800 symbols/second--so
>   it's not the throttle *per se*, but rather the way that work "chunks"
> get scheduled in Gnu Radio.  With a "fast" source, you dont find yourself
>   in a situation where there aren't enough "chunks" to keep things busy.
> 
> But a very reasonable example would be something like a cross-band
> digital repeater application, where bits/symbols would be arriving
>   at the "channel rate", and need to leave the Tx in something at least
> approaching real time--you certainly need to have a bit of
>   elastic buffering to compensate for clock-skew between the two sides,
> but several-tens-of-seconds of latency isn't likely to be very
>   useful in the real world.
> 
> Note that I'm not criticizing anybody or anything.  I'm making
> observations, and I *do* understand *why* it is the way it is.
>   My little test flow-graph failed the "least astonishment test", which
> is why I felt I needed to comment.
> 
> Would it be reasonable to open a discussion about this class of
> flow-graph?  I think they can be characterized as flow-graphs with
>   a low symbol rate, and high interpolation (which I think is where the
> buffer-multiplier effect may be coming into play).  In such flow-graphs,
>   would it be reasonable to be able to "tweak" the scheduler to deal
> with this type of situation?  I have little insight into how the scheduler
>   works in detail, but I think I understand the "fits and starts" that I
> was observing.
> 
> So, is this a reasonable discussion topic?  Are other folks working on
> "stuff" that will run into part of the performance diagram I ran
>   into yesterday?  Or is everyone else working on high-event-rate type
> signal chains?

Marcus,

This is certainly a reasonable discussion topic.
I suggest before wading in that you first enable the scheduler logging
that I mentioned in a prior post and take a look at that.

Feel free to send me the logs too.

What we're looking for is which block is forcing the large chunk size.
If you were reading from a file using for example gr.file_source, it
won't return until until it's completely filled up the downstream
buffer given to it.  That's just how it's written.

A trivial change would be to have it loop until it it read
min(N_USER_SPECIFIED_ITEMS, noutput_items) items.

Eric