I have a loop block that I wanted to run very slow (1Hz), and put a
throttle block set to rate 1. Unfortunately, it seems to tear through
the first 8-9k samples in a blink before it slows down. Is there an
alternative implementation of the throttle block that would work at very
slow speeds? Perhaps rather than memcopying the entire batch of samples
passed into the work function, it would loop copy and deal with rate and
sleeps during the loop? Obviously this wouldn’t be optimal for fast rate
blocks, but what about creating a separate throttle optimized for slow
data rates?
On Sat, Jul 2, 2011 at 2:27 PM, Brett L. Trotter
[email protected]wrote:
I have a loop block that I wanted to run very slow (1Hz), and put a
throttle block set to rate 1. Unfortunately, it seems to tear through
the first 8-9k samples in a blink before it slows down. Is there an
alternative implementation of the throttle block that would work at very
slow speeds? Perhaps rather than memcopying the entire batch of samples
passed into the work function, it would loop copy and deal with rate and
sleeps during the loop? Obviously this wouldn’t be optimal for fast rate
blocks, but what about creating a separate throttle optimized for slow
data rates?
Yes, I think you could make something like that work, but you’re right
that
it would have to be done for only small data rates. If you come up with
a
general solution to this, we can work on getting it into the code.
This comes back to the general issues others have had with the fact that
the
schedule optimizes for throughput and doesn’t really care about issues
like
what you are seeing. It pops up more in the case where people want to
minimize latency.
Tom