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.
--n
On Tue, 2015-06-16 at 12:01 -0400, address@hidden
wrote:
> From: Thanasis Balafoutis <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [Discuss-gnuradio] CPU usage when hdlc framer is used
> Hi,
>
> CPU usage goes to 100% when the hdlc_framer block is used!
> To verify this I did the following tests:
>
> 1. message_strobe_random ----> message_debug (CPU usage 2%)
> 2. message_strobe_random ----> hdlc_framer----> null_sink (CPU usage 100%)
>
> Any idea how can I avoid this overload?
Off the cuff, it appears the hdlc_framer needs at least one fix:
1. If oidx == 0, it should use a blocking fetch of a message here:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/hdlc_framer_pb_impl.cc#L132
If oidx != 0 then using the current delete_head_nowait() call is
correct.
This is probably the major contribution to the CPU spinning.
Maybe some other changes to the hdlc_framer block might help for high
sample rates:
2. The block does a number of dynamic std:vector<> and pmt
instantiations and destructions in a call to work(). If you use the
oprofile tools, those likely generate some measureable overhead
attributable to malloc() and atomic increments and decrements related to
boost shared pointer for the PMTs. You might gain a few % CPU back by
avoiding the constant allocation & deallocation by converting the block
to use class variables where it makes sense.
3. The block also has 2 memcpy()'s in a call to work(). If you can
figure out an way to optimize one away, you'll get some savings. I
don't see an obvious way to do that right now.
Also, your flowgraph does not have a throttle block to enforce a
realistic timing for the sample rate you have chosen, so the hdlc_framer
is going to run as fast as it can. The null sink essentially ensures
there is always output buffer space for the hdlc_framer.
> Thank you
> Thanasis
Regards,
Andy