discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning:


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning:
Date: Sun, 7 Jul 2013 04:25:40 -0400

On Fri, Jul 5, 2013 at 5:01 AM, Manu T S <address@hidden> wrote:
> A block that i designed takes a vector of length 408 with numpy.int32
> components. Work function just copies input to output. Work function
> definition is given below.
> ----------------------------------------------------------------------------------------------------
>     def work(self, input_items, output_items):
>         for i in range(len(input_items[0][0])):
>             print input_items[0][0][i],
>             output_items[0][0][i] = input_items[0][0][i]
>         return len(input_items[0])
> -----------------------------------------------------------------------------------------------------
>
> I'm getting the following warning.
>
> gr::buffer::allocate_buffer: warning: tried to allocate
>    40 items of size 1632. Due to alignment requirements
>    128 were allocated.  If this isn't OK, consider padding
>    your structure to a power-of-two bytes.
>    On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
>    40 items of size 1632. Due to alignment requirements
>    128 were allocated.  If this isn't OK, consider padding
>    your structure to a power-of-two bytes.
>
> What could be the reason for this warning? What could be done to correct
> this?
>
> --
> Manu T S

Manu,

This has more to do with your io_signature declaration in the
constructor than the work function. It's simply that for memory
handling purposes, the buffers are set up to use multiples of pages,
and you are asking for a strange size. Basically, this should still
work, but you might be using a lot more memory for your buffers than
required.

I wouldn't worry about this for now. I'm assuming this is for your
GSoC project? If so, just keep going and make sure you get the math
right. You'll want to move this into a C++ block eventually, anyways,
and do further optimizations there. We can worry about this problem at
that point.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]