Forum: GNU Radio how do I disable this buffer warning?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Vincenzo P. (Guest)
on 2007-06-04 14:20
(Received via mailing list)
Hi List,
the warning is ok, but once I have realized I've got no problem with it
how do I prevent it from spoiling the continuity of my status
messages? :D

can anyone suggest how to disable it

many thanks
best regards

vincenzo
Eric B. (Guest)
on 2007-06-04 19:05
(Received via mailing list)
On Mon, Jun 04, 2007 at 12:19:21PM +0200, Vincenzo P. wrote:
> vincenzo
> > ---------------------------------------------------------
> > Connecting Outer Interleaver, Bit Extractor, Inner Encoder
> > Done
> > ---------------------------------------------------------
> > Connecting Inner Interleaver
> > gr_buffer::allocate_buffer: warning: tried to allocate
> >    5 items of size 6048. 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.

It's printed out on line 126 of gr_buffer.cc.

Hack away ;)

Eric
Trond D. (Guest)
on 2007-06-04 20:46
(Received via mailing list)
2007/6/4, Eric B. <removed_email_address@domain.invalid>:
> >
> > >    On this platform, our allocation granularity is 4096 bytes.
>
> It's printed out on line 126 of gr_buffer.cc.
>
> Hack away ;)
>
> Eric

I also get a lot of messages like this, and I suspect it is the curse
for doing vector processing on vectors of length other than powers of
two. Am I correct?


--
Trond D.
Chris S. (Guest)
on 2007-06-04 20:57
(Received via mailing list)
Trond D. wrote:
> I also get a lot of messages like this, and I suspect it is the curse
> for doing vector processing on vectors of length other than powers of
> two. Am I correct?

You get these messages when your blocks cannot keep up with the rate of
data coming from the source.  Some blocks (FFTs come to mind) operate
more efficiently when given data in chunks of powers of two, but I would
guess changing your vector length wouldn't help too much.

You can write the data out to a file and read it back in.  This way you
will not lose any data (but you will run slower than real time).

Chris
Matt E. (Guest)
on 2007-06-04 21:05
(Received via mailing list)
>
> I also get a lot of messages like this, and I suspect it is the curse
> for doing vector processing on vectors of length other than powers of
> two. Am I correct?


Exactly.  What is happening is that there is a very efficient way of
implementing circular buffers using a virtual memory trick.  By having 2
consecutive virtual page mappings to the same physical page, you don't
have to check for the wrap at the end of the buffer back to the
beginning.  it allows us to implement very efficient fifos between
blocks.

The problem is that the VM trick I described above requires 2 things:
    The FIFO is an integral number of pages
    The FIFO is an integral number of "items"

On X86 and x86-64, pages are 4096 bytes.

Therefore, the FIFO size must be equal to the least common multiple
(LCM) of 4096 and your item size. Thus, there is no problem when your
items are things like bytes or complex numbers (8 bytes) -- the FIFO
becomes 1 page of 4096 bytes.

However, if you have an item size of 9 bytes for example, you need a
bigger fifo.  LCM(4096,9) equals 9*4096 since they are relatively
prime.  The cost is having a larger fifo taking up more memory, or more
importantly, more CACHE space.

It would be much worse if you chose an item size of say 4095.  The LCM
in that case is 4095*4096, or just under 16 megabytes.

Matt
Matt E. (Guest)
on 2007-06-04 21:08
(Received via mailing list)
Chris S. wrote:
> You can write the data out to a file and read it back in.  This way
> you will not lose any data (but you will run slower than real time).

This is not correct.

What you need to understand from the warning is that:

    a - your system will use more memory than if you didn't have the
warning
    b - your system might run slower than if you didn't have the warning

Your system WILL STILL RUN CORRECTLY.  This is only a performance
warning, NOT an error.

Please see my other message for clarification.

Matt
This topic is locked and can not be replied to.