I’m curious about this statement in
$PYTHONPATH/gnuradio/gr/flow_graph.py
# We could scan the graph here and determine individual sizes
# based on relative_rate, number of readers, etc.
In the meantime, it would be nice to be able, somehow, to tweak the
global buffer size from inside an application, without having to
edit flow_graph.py manually. Or a GR_BUF_SIZE environment variable.
Because: One of my simple test apps works 600% faster using 4k buffer
instead of 32k, since it doesn’t have to wait for stale data to clear.
Seems like the ideal setting for a ‘tight’ app would be as small as
possible that still runs without hiccups, to minimize delays in
transmit/receive turnaround time, etc.
–Chuck
On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
Because: One of my simple test apps works 600% faster using 4k buffer
instead of 32k, since it doesn’t have to wait for stale data to clear.
Chuck, can you point me at the code for the application?
I wouldn’t expect the size of buffer to matter as long as each block
returned all the data asked for on each call to work.
Seems like the ideal setting for a ‘tight’ app would be as small as
possible that still runs without hiccups, to minimize delays in
transmit/receive turnaround time, etc.
–Chuck
Again, please point me to the code.
Eric
On Wed, 2006-07-05 at 09:39 -0700, Eric B. wrote:
On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
Because: One of my simple test apps works 600% faster using 4k buffer
instead of 32k, since it doesn’t have to wait for stale data to clear.
Chuck, can you point me at the code for the application?
I wouldn’t expect the size of buffer to matter as long as each block
returned all the data asked for on each call to work.
It’s not an issue in continuous flow - the testing app had a problem
after changing DUC/DDC and restarting everything, it took about 750mSec
between samples to get a clean transition. I just tried it with a
buffer of 4k and was able to use 100mSec between samples.
Just curious if there could be easy way to specify the buffer size in
flow_graph.py - the comments seem to suggest there is a use for
‘automatic optimization’ but just another knob to tweak would be ok
with me. Other applications for minimal working buffer would be
shortning the delay between speaking into a mic and the transmitted
audio, or adjusting an antenna and seeing/hearing the results.
Script attached - the ‘problem’ shows up in the long ‘else’ clause
of the OnUpdate() function. Too small timer delay and the next few
data points are repeats of the one right before changing cordic freq.
–Chuck
On Wed, 2006-07-05 at 09:39 -0700, Eric B. wrote:
edit flow_graph.py manually. Or a GR_BUF_SIZE environment variable.
Because: One of my simple test apps works 600% faster using 4k buffer
instead of 32k, since it doesn’t have to wait for stale data to clear.
Chuck, can you point me at the code for the application?
I wouldn’t expect the size of buffer to matter as long as each block
returned all the data asked for on each call to work.
No biggie in the grand scheme, for one particular app with lots of
fg starting and stopping here’s two plots with the only change being
self.fixed_buffer_size = 321024 or 41024:
4k buffer:
http://webpages.charter.net/cswiger/80m_filter_4kbuf.jpg
nice, smooth and fast - 10 data points per second. But with
default 32k buffer:
http://webpages.charter.net/cswiger/80m_filter_32kbuf.jpg
no good. That’s where I had to slow it down to 3/4 second per
data point (bletch).