On Tue, Dec 07, 2010 at 11:36:19AM +0100, Anton Blad wrote:
On Mon, 29 Nov 2010 09:30:11 -0800, Eric Blossom e...@comsec.com wrote:
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
Hi Eric,
Thanks for your reply. There are two obvious drawbacks with the simple
fix: the latency will still be higher than necessary, and processing large
chunks will not be possible. I have the following alternative suggestion:
* Create a new policy governing class (gr_tpb_policy_governor?) with the
purpose of keeping track of which blocks are making progress. The class
contains a condition variable that source blocks wait on in case the
scheduling policy disallows adding more samples to the flowgraph.
* Create an instance of gr_tpb_policy_governor in the gr_scheduler_tpb
constructor and tell it the number of blocks in the flattened flowgraph.
* Add a reference to the gr_tpb_policy_governor instance in the
gr_tpb_detail blocks. Update the states of the blocks in
gr_tpb_detail::set_{input,output}_changed and in
gr_tpb_thread_body::gr_tpb_thread_body depending on
gr_block_executor::state.
The policies I can think of being useful are:
* flooding: the current policy, for performance
* active_blocks: block sources if more than a minimum number of blocks are
processing concurrently, in order to reduce latency. Could be set to 1 to
give the behavior of the single threaded scheduler.
* num_samples: block sources if more than a minimum number of samples are
processed currently, in order to reduce latency while still ensuring
acceptable performance.
I guess that the main drawback of this proposal is that the
gr_tpb_policy_governor will contain a very heavily used mutex.
Comments? If I do these changes, will the GNU Radio team be interested in
a patch?
If it can be done cleanly and simply in a way that doesn't reduce the
performance too much (say 3%) for those who are using flooding, then
I think we'd consider it. The measure of performance should be total
CPU time (== user + sys).
I do have some questions about how you'd tune the active_blocks and
num_samples cases...
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
