# PDU\_to\_tagged\_stream consumes 100% CPU even though it is throttled! **URL:** \ **Category:** GNU Radio\ **Created:** [January 14, 2015, 11:30pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818 "2015-01-14T23:30:02Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 14, 2015, 11:30pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/1 "2015-01-14T23:30:02Z")
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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 7:15am UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/2 "2015-01-15T07:15:58Z")
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. > **[Re: \[Discuss-gnuradio\] delete\_head\_blocking()](https://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00552.html)** Best, Bastian ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 9:14am UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/3 "2015-01-15T09:14:23Z")
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 > **[Want to know how to live #LikeABosch?](https://www.bosch.com/)** > > Moving stories and inspiring interviews. Experience the meaning of "invented for life" by Bosch completely new. Visit our international website. Tel. +49(711)811-8809 Fax +49(711)811-1052 Mobil +49(172)5630639 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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) [[mailto: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: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. > **[Re: \[Discuss-gnuradio\] delete\_head\_blocking()](https://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00552.html)** Best, Bastian * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 10:00am UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/4 "2015-01-15T10:00:52Z")
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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 1:59pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/5 "2015-01-15T13:59:59Z")
> 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 🙂 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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 1:51pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/6 "2015-01-15T13:51:58Z")
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 🙂 Greetings, Marcus ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 2:27pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/7 "2015-01-15T14:27:35Z")
On Thu, Jan 15, 2015 at 2:01 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 2:03pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/8 "2015-01-15T14:03:03Z")
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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 2:58pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/9 "2015-01-15T14:58:52Z")
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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 3:00pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/10 "2015-01-15T15:00:06Z")
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 ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 5:10pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/11 "2015-01-15T17:10:13Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\ **Post date:** [January 15, 2015, 7:37pm UTC](https://www.ruby-forum.com/t/pdu-to-tagged-stream-consumes-100-cpu-even-though-it-is-throttled/233818/12 "2015-01-15T19:37:53Z")
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