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

[Marcus Müller]

Hi Andy,
if I understand you correctly, you think the situation calls for
something like a "wait for message flag" that a block would need to set
every work call?

Best regards,
Marcus

On 06/16/2015 10:25 PM, Andy Walls wrote:
> 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
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio