On 03/31/2014 09:05 PM, Marcus Müller wrote:
> That environment variable is "GR_SCHEDULER":
>
>> git grep getenv
> ...
> gnuradio-runtime/lib/top_block_impl.cc:char *v = getenv("GR_SCHEDULER");
> ...
>
> and you need to set it to "STS":
>
> export GR_SCHEDULER=STS
> ./my_gr_flowgraph.py
Please
Interesting results at least for situations when the queue is before/after FFT.
It is like the queue is starving the FFT. You could try to see what is the
actual data that the scheduler passes to the FFT and the other blocks in each
cases. From my experience, the smaller the chunks are the slowe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
That environment variable is "GR_SCHEDULER":
> git grep getenv
...
gnuradio-runtime/lib/top_block_impl.cc:char *v = getenv("GR_SCHEDULER");
...
and you need to set it to "STS":
export GR_SCHEDULER=STS
./my_gr_flowgraph.py
Greetings,
Marcus
On 31
The reason why I bring this up, is because I think I may have found an error in
the scheduler; or at least a shortcoming in the way that it schedules different
‘scheduling domains’.
I have several sub-flowgraphs in my flow graph. What I mean by this is that my
program (with a single top block)
On older gnuradio releases there was an environment variable to set so that it
will switch to single threaded scheduler. Cannot remember the name, though.
Bogdan
On Monday, March 31, 2014 7:35 PM, Tommy Tracy II wrote:
Dear list,
Is there any way to use the single-threaded scheduler over
Dear list,
Is there any way to use the single-threaded scheduler over the
thread-per-block scheduler without rebuilding Gnu Radio?
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
signature.asc
Description: Message
