For testing purposes I use
vector source (byte ) -> vector to stream -> throttle -> [blocks to
test]
In the vector source “repeat” is set to “yes” and the sample rate is set
to 1024 ( and in the throttle block , too ).
I would expect that the throttle delivers 1024 samples every second. But
I see that the throttle delivers 32768 bytes about every 32 seconds. (
Which is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered every
second ?
– Volker
Hi,
For testing purposes I use
vector source (byte ) -> vector to stream -> throttle -> [blocks to test]
In the vector source “repeat” is set to “yes” and the sample rate is set to
1024 ( and in the throttle block , too ).
I would expect that the throttle delivers 1024 samples every second. But I
see that the throttle delivers 32768 bytes about every 32 seconds. ( Which
is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered every
second ?
Excpected I wouldn’t say so, but there is no guarantee basically. Only
long term average rate is correct, the rest is kind of up to the OS
scheduler that says when thread runs …
At every iteration of the work() function, the block will let as much
sample pass depending on the time since the last call.
But for very very low rates (like 1k/s) that’s probably not going to
go over very well because things tend to be processed by “block”.
Cheers,
Sylvain
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Volker,
yes, that is expected behaviour. Most probably 
For explanation: Since GNU Radio itself always passes around multiple
items at once (so your work doesn’t get called), all throttle can do is
limit the average rate, unless it would consume one input item at a
time, stall work as long as necessary and then output that one item.
For higher sample rates (where the flow graph is nearly CPU-limited),
which is the original use case of throttle (stopping GNU Radio from
completely clogging the CPU) this would imply a considerable overhead.
What you can try is call the public
gr::block::set_max_noutput_items(int) method on your throttle block
prior to starting the flow graph. This should tell the scheduler to
call the throttle’s work function with smaller numbers of input
samples (also, it reduces the output buffer size if that is feasible
for the downstream block).
Also, try smaller values for the max_output_buffer size of the vector
source, maybe (that could be even accessible in the GNU Radio
companion block property dialog).
one more question in that context: why the vector to stream? the
vector source can output single samples, too. Just set the vector
length to 1.
Greetings,
Marcus
On 16.03.2014 17:35, Volker S. wrote:
– Volker
_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTJdimAAoJEBQ6EdjyzlHtheAH/iv6UnTFsr0z+BftZO535iDu
kKZa4ik0wnYMv83byngbqX9RClzCATeTxSKgav9EwKIF66jAwH3l5Ojb+wv9SA4C
4gSttXCktHwCU7lcSPaAQMQzJIKOEJUlHPgd67iGxMVuu67RPDZoFyQiWSHaRaV1
kwhk4KgZs/Ku+ORvaMNJk3caTs9OUJkBvbqxvr1DCWZyHXS/CDh3is7XJMONcLRR
d0XzELkMic9MdbkT/ljnjujlPaMtlw+VM3SvU8Cfvm/lLif9KsLE0PdjF4yWbFpZ
Ct+RoD1/HZMUhceBZL804ty7xlNrt73B7jZgT9ZmgzxkEqoyw54UeoXnrIZeIjg=
=+VI7
-----END PGP SIGNATURE-----
Thanks for the tips.
Setting the Max Output bufferin the throttle block did the trick.
Yes, the vector to stream block can be avoided. The default vector
length is 1 in grc.
Now testing works much smoother.
Good to know.
– Volker
Am 16.03.2014 18:00, schrieb Marcus M.: