PDU_to_tagged_stream consumes 100% CPU even though it is throttled!

GNU Radio
1

Hi all,

I have the following problem that is been bugging me for quite some time
now,
and I would like to solicit your help.

I made a hier block in GRC (called “test_pdu_to_tag”) with:

pad_source—>pdu_to_tagged_stream–>pad_sink

(I also made the pad_source “optional” and the pad_sink “required”)

After compiling this block, I test it using the following GRC test

test_pdu_to_tag–>throttle (at 100Hz!)–>null_sink

(observe that the “test_pdu_to_tag” does not have an input)

==============
When I run this I get that the CPU load goes to 100%.

can anyone help me figure out why this is happening?
This is all with the latest master on a Fedora 19.

Thanks
Achilleas

2

Hi,

On 01/14/2015 11:29 PM, Achilleas A. wrote:

After compiling this block, I test it using the following GRC test

test_pdu_to_tag–>throttle (at 100Hz!)–>null_sink

(observe that the “test_pdu_to_tag” does not have an input)

==============
When I run this I get that the CPU load goes to 100%.

can anyone help me figure out why this is happening?
This is all with the latest master on a Fedora 19.

AFAIK, pdu_to_tagged_stream is busy-waiting for new PDUs (at least in
June 2013 it was) and always uses 100% CPU.

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00552.html

Best,
Bastian

3

Hi List,

from my understanding of the code, this caveat still exists. And I have
the same problem with this block as Achilleas.

Johnathan: As you wrote in the cited post that you would be working on
that after 3.7.0, could you please give an update on the state of work?
How can we support?

Mit freundlichen Gren / Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobil +49(172)5630639
[email protected]

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschftsfhrung: Dr. Volkmar
Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kbel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller

-----Ursprngliche Nachricht-----
Von: discuss-gnuradio-bounces+stephan.ludwig2=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+stephan.ludwig2=removed_email_address@domain.invalid]
Im Auftrag von Bastian B.
Gesendet: Donnerstag, 15. Januar 2015 07:15
An: [email protected]; [email protected]
Betreff: Re: [Discuss-gnuradio] PDU_to_tagged_stream consumes 100% CPU
even though it is throttled!

Hi,

On 01/14/2015 11:29 PM, Achilleas A. wrote:

After compiling this block, I test it using the following GRC test

test_pdu_to_tag–>throttle (at 100Hz!)–>null_sink

(observe that the “test_pdu_to_tag” does not have an input)

==============
When I run this I get that the CPU load goes to 100%.

can anyone help me figure out why this is happening?
This is all with the latest master on a Fedora 19.

AFAIK, pdu_to_tagged_stream is busy-waiting for new PDUs (at least in
June 2013 it was) and always uses 100% CPU.

http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00552.html

Best,
Bastian

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

Hi,

Yes, this looks like a pretty big issue to me too. 100% CPU spinning
is just not acceptable, ever.

To me it look like all it’s missing is a
basic_block::delete_head_blocking with a timeout. Then the
pdu_to_tagged_stream_impl::calculate_output_stream_length could just
use that with a reasonably small timeout (like 100ms or so) so that it
waits on a message but if none comes, it still handout control back to
the caller from time to time (which I think is required for stop() to
work).

Is there anything that wouldn’t work with this approach ?

Cheers,

Sylvain

5

Just a warning:
pdu_to_tagged_stream saw significant change in the middle of last december;
so make sure you’re all talking about the same version :slight_smile:

Just tried with the last version and the issue is definitely there.

I’m not entirely sure what motivated the fact of making it a TSB
source, but that didn’t seem to change the problem.

Cheers,

Sylvain

6

Just a warning:
pdu_to_tagged_stream saw significant change in the middle of last
december; so make sure you’re all talking about the same version :slight_smile:

Greetings,
Marcus

7

On Thu, Jan 15, 2015 at 2:01 PM, Marcus Müller
[email protected] wrote:

Stupid question:
at least in the old version of the code, the current message was popped
from the queue using delete_head_nowait().
Why don’t we just delete_head_blocking() and – block?

I think this would prevent the flow graph from stopping because it
would block there indefinitely.
For that to work, the condition variables of each message port would
have to be poked by the runtime on shutdown.

That’s why I proposed a version of delete_head_blocking with a timeout
so we can handover control from time to time.

(this is from a quick glance at the code, I might have missed some
stuff).

Cheers,

Sylvain

8

Stupid question:
at least in the old version of the code, the current message was popped
from the queue using delete_head_nowait().
Why don’t we just delete_head_blocking() and – block?

Greetings,
Marcus

9

Hi,
On 01/15/2015 02:26 PM, Sylvain M. wrote:

Why don’t we just delete_head_blocking() and – block?
I think this would prevent the flow graph from stopping because it
would block there indefinitely.
Yes, a friendly cohabitant of this lab just told me to rtfm and also
consider it; I do agree, I think currently this would stop stop() from
stopping().
For that to work, the condition variables of each message port would
have to be poked by the runtime on shutdown.

That’s why I proposed a version of delete_head_blocking with a timeout
so we can handover control from time to time.
Yeah, but why don’t we just poke that variable on stop()? Ignoring the
work calls that might under non-stop() circumstances might occur from
message queue handling would imho be perfectly fine when stop() has been
called.

Greetings,
Marcus

10

Some background: It was made a TSB block because TSB source blocks
weren’t possible until recently, and that’s an example use-case. Doesn’t
solve the spinning issue.

On 01/15/2015 02:26 PM, Sylvain M. wrote:

That’s why I proposed a version of delete_head_blocking with a timeout
so we can handover control from time to time.

We’ve always considered blocking in blocks as harmful, but maybe we need
to think about this a bit more. What we’d definitely need is a way to
interrupt the blocking.

However, what would really solve the issue is if we could define
requirements for msg->stream blocks, similar to ‘ninput items required’.

M

11

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

12

Hi,

A change to a blocking call with a timeout would work as a “short” term fix.
Ok, I’ll code and test that solution.

Cheers,

Sylvain