Re: [Discuss-gnuradio] TPB scheduler fills block buffers

[Eric Blossom]

On Mon, Nov 29, 2010 at 08:42:14AM +0100, antonb wrote:
> Hi,
> 
> I am writing an application for which I want to keep the latency to a
> minimum, and this involves trying to keep the buffers between the blocks as
> empty as possible. Basically, I have a source block with an element size of
> 512 bytes that accepts data through a public member function. If there is
> no data to transmit it will produce one empty packet to keep the USRP busy.
> The scheduler keeps asking for 64 items and I give it one. This goes on
> until its write buffer is full. The processing latency (from the source
> block to the USRP) of the first items is a few ms, but this grows to well
> over a second due to the large amounts of buffered data.
> 
> Looking at the behavior of the single threaded scheduler, it seems it is
> trying to keep the latency low by only requesting data from source blocks
> when the other blocks fail to produce anything. However, the thread per
> block scheduler does not seem to care about whether a block is a source
> block or not. Is there any way I can configure it to do this? Is there any
> other approach for solving this problem?
> 
> Thankful for any help,
> Anton Blad

Hi Anton,

There's been some discussion about this over the past few months.
Probably the easiest way to fix this problem is to limit the usable
size of the buffers in the processing chain.  This is a relatively
small change, that would allow an application developer to control the
worst case amount of buffering that is used in the graph.  By default,
we allocate buffers on the order of 32KiB, then double that size so
that we can double buffer under the TPB scheduler. (Optimizing for
throughput.)

The current implementation requires that the physical size of the
buffers be a multiple of the page size.  The fix I'm proposing leaves
that constraint in place (it's hard to remove for a variety of
reasons), but allows the specification of a limit on the total number
of samples allowed in the buffer.  Thus, if want low latency, you
could specify a limit of 512 bytes (or less for that matter), and the
total buffering would be drastically reduced from what's currently
used.

I won't have time to look at this until after the new year, but if
you're interested in looking at it, the primary place to look is
gnuradio-core/src/lib/runtime/gr_buffer.{h,cc}.  Basically you'd want
to limit the amount of space that it reports is available for writing
to min(<whats-physically-available>, <your-limit>)

Eric