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? 
can anyone suggest how to disable it
many thanks
best regards
vincenzo
On Mon, Jun 04, 2007 at 12:19:21PM +0200, Vincenzo P. wrote:
vincenzo
Connecting Outer Interleaver, Bit Extractor, Inner Encoder
DoneConnecting 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
2007/6/4, Eric B. [email protected]:
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.
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
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
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