On Thu, Feb 6, 2014 at 9:14 PM, Miklos M. [email protected]
Thanks for the answer! I have considered both approach already. What
you are saying is that set_relative_rate cannot capture this scenario,
so it is impossible to set different relative rates, right?
Right; relative_rate as a value is defined as a single value for the
entire block. you can consume and produce at different rates for each
Where exactly are the relative rates used in gnuradio core? Only for
the buffer size calculations or are they also used during runtime?
Yes, mostly the initial buffer size calculation. It’s also used to
update the item offset value of a tag through a rate-changing block.
By the way, the vector approach does not scale ideally: if I increase
the size of vectors (to 100000 samples) or use set_output_multiple
with that large value then the performance of the block is degraded,
and I do not really understand why. If the block does pure streaming
(e.g. add) and does not require large quantities of data, then
everything works fine. I do not want to use messages, because the data
is processed (filtered, length changed, etc) along with other
transformations. Anyhow, what I am getting at that there is no good
way of processing very large blocks of data.
Use gr-perf-monitorx (or in GRC just look for Performance Monitor) if
you have ControlPort enabled and building properly . You’ll
likely see the buffer in front of your block backing up while the
output buffer is fairly empty as the scheduler has to dump lots of
data into it before anything else can go, so you’ll be starving the
Another model is to try and handle the state internally. Just allow
data to flow in from each data stream and keep internal buffers. This
might allow you to work with the scheduler better.
I’m interested to see if you can get an approach that works well with
your problem. So far, what you’re trying to do seems somewhat of a
non-standard use-case for GNU Radio, but I can see more people trying
to do this kind of processing in the future. Would be good to know
both the limits and why.