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, Jun 16, 2015 at 9:53 AM Andy Walls <a...@silverblocksystems.net> wrote: > On Tue, 2015-06-16 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org > wrote: > > > From: Thanasis Balafoutis <abalafou...@gmail.com> > > To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> > > 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
