Re: [Discuss-gnuradio] CPU usage when hdlc framer is used

[Andy Walls]

On Tue, 2015-06-16 at 12:27 -0700, Johnathan Corgan wrote:
> On Tue, Jun 16, 2015 at 10:16 AM, Nick Foster <address@hidden>
> wrote:
>  
>         Issue #1 is likely the problem. Thanks for pointing that out,
>         Andy! The other two issues should be pretty miniscule in
>         overhead, but are probably good ideas nonetheless. The block
>         was written for clarity rather than for speed, but even so it
>         shouldn't be particularly heavy-duty.


> In the future, we plan to allow designating a non-empty message queue
> as a prior condition to be satisfied before the scheduler calls
> work(), thus it will won't ever be necessary to block inside work
> directly on the queue itself.  This is a common issue with source
> blocks that rely on input message ports for content.

Hi John,

That will help for blocks which can somehow guarantee that every
incoming message will never generate more than noutput_items in every
call to work.  Otherwise the block is going to have to save away the
residual output items, to be output in a later call to work().  There is
no need to block on message input to output those residual output items.

I.e. in a call to work():
0. output any residual items saved from last call to work()
1. grab message off queue (making a decision to block or not as
appropriate)
2. generate items, which may number more than noutput_items
3. store any residual items for output for next call to work()
4. return number of items generated up to noutput_items


The hdlc_framer looks like it has this notion of a residual in
d_leftovers.

Although different from GnuRadio internal messaging, some internal fixes
I made to the gr-zeromq sub_source_impl.*, to work reliably and at high
throughput, also needed to deal with residual parts of messages that
could not be sent out in the current call to work() and had to deal with
context depending blocking when checking for messages.  (The current
sub_source_impl.* on the master branch discards the items in incoming
ZeroMQ messages that are beyond noutput_items - not a nice thing to do.)

My $0.02

Regards,
Andy