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.
57371349a0e4580b0362a0441ef5094b?d=identicon&s=25 Vincenzo Pellegrini (Guest)
on 2007-06-04 12: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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-06-04 17:05
(Received via mailing list)
On Mon, Jun 04, 2007 at 12:19:21PM +0200, Vincenzo Pellegrini 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
Bb3ff9c86361ea921a64632a4c46e824?d=identicon&s=25 Trond Danielsen (Guest)
on 2007-06-04 18:46
(Received via mailing list)
2007/6/4, Eric Blossom <eb@comsec.com>:
> >
> > >    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 Danielsen
815d7689c14621a2a5ed60b8bcde29b8?d=identicon&s=25 Chris Stankevitz (Guest)
on 2007-06-04 18:57
(Received via mailing list)
Trond Danielsen 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
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2007-06-04 19: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
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2007-06-04 19:08
(Received via mailing list)
Chris Stankevitz 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.