Hi Miklos,
with sync blocks and fixed rate decimators/interpolators, the scheduler
inherently knows how many buffers to allocate etc down the signal
processing line to always keep all blocks busy.
With general blocks, this is not possible; calls to forecast are
necessary to determine how much
Hi Marcus,
On Thu, Aug 22, 2013 at 12:00 PM, Marcus Müller wrote:
> Just to add my two cents:
> Depending on your actual application, your large vectors might not actually
> quite fit the idea of "streams"; they might, for example, be a valid,
> decoded network packet or something of the like. If
Just to add my two cents:
Depending on your actual application, your large vectors might not actually quite fit the
idea of "streams"; they might, for example, be a valid, decoded network packet
or something of the like. If they don't need sample-synchronous handling, using messages
to pass the
Hi Martin, Yes, I know of stream tags, but it would just make the
blocks complicated: now I can rely on the fact that data is coming in
a multiple of the vector length. For now, padding solves my immediate
needs, but it is not an ideal solution. Miklos
On Wed, Aug 21, 2013 at 11:18 PM, Martin Brau
Hi Marcus,
Yes, I understand the page size limitation. However, if your vector is
1234 bytes, then you can happily allocate 4096 size buffer, but the
the block you always give out the multiple of 1234 byes (i.e. 1, 2 or
3 vectors). The address space wrapping would work fine, so the start
of the ve
On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote:
> So is there a way to work with large odd length vectors which does not
> have this buffer allocation problem, and does not require padding? It
> seems to me that it could be supported: regular streams but the vector
> size would be ve
Yes, this is what I am doing, but it is not very nice, and you cannot
easily mix in blocks that want to work at the stream level. What
really bugs me that I think the scheduler could figure all out, and
treat my vectors as a stream, allocate nice buffers (who cares if the
vector fits in the buffer
Yes, this is what I am doing, but it is not very nice, and you cannot
easily mix in blocks that want to work at the stream level. What
really bugs me that I think the scheduler could figure all out, and
treat my vectors as a stream, allocate nice buffers (who cares if the
vector fits in the buffer
On Wednesday, August 21, 2013, Miklos Maroti wrote:
>
> I have many sync blocks that work with large fixed size vectors, e.g.
> converts one vector of size 12659 to another with size 18353. I have
> just multiplied the sizeof(gr_complex) with 12659 and 18353 in the
> signature. However, when the f
Hi!
I have many sync blocks that work with large fixed size vectors, e.g.
converts one vector of size 12659 to another with size 18353. I have
just multiplied the sizeof(gr_complex) with 12659 and 18353 in the
signature. However, when the flow graph is running, then I get a
warning about paging: t
10 matches
Mail list logo
