Re: [Discuss-gnuradio] How to use a single-threaded scheduler

[Tommy Tracy II]

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) has several disjoint flow graphs with separate sources and sinks. I say that each of these sub-flowgraphs are in separate 'scheduling domains' because they _should_ be scheduled independently by the same scheduler. Is this an incorrect understanding of mine?

I have a test system that streams floats from a file through a throttle, into a series of FFTs, through a custom throughput block (which tells me the throughput of the data flowing through it) , and into a file sink. A necessary component of my system is a queue that temporarily holds ‘windows’ to be computed via the FFT, and then another queue after the FFTs that holds the resulting windows. Because this queue ties two sub-flowgraphs together, they should work in tandem. I ran the system without queues, with a single queue, and with two queues to get throughput values. My results were not as I had predicted:

Queue_sink: is a Flowgraph sink that grabs the data from input buffer, populates ‘window’ vectors, and pushes a reference to the vectors into a boost lock free queue.

Queue_source: is a Flowgraph source that grabs ‘window’ references from the lock free queue, and populates the output buffer.

If my system has two queues:

[file source] - [throttle] - [input queue sink]  ||INPUT QUEUE|| - [input queue source] - FFTs - [output queue sink] - ||INPUT QUEUE|| - [output queue source] - [throughput] - [file sink]

With this configuration, I get an average throughput of : 0.235 MS/S (which is ~ 80% less than the queue-free system)

Here’s where it gets weird!

If my system has ONE queue, placed before the FFTs:

[file source] - [throttle] - [input queue sink]  ||INPUT QUEUE|| - [input queue source] - FFTs - [throughput] - [file sink]

With this configuration, I get an average throughput of : 0.208 MS/S! (not significantly less than the 2-queue system, but still less!)

If my system has ONE queue, placed after the FFTs:

[file source] - [throttle] - FFTs - [output queue sink] - ||INPUT QUEUE|| - [output queue source] - [throughput] - [file sink]

With this configuration, I get an average throughput of : 0.409 MS/S! (which is ONLY 6% less than the queue-free system)

This leads me to believe that there may be a flaw in the scheduler. Do I have an incorrect understanding of how it should work? 

Tommy James Tracy II

Ph.D Student

High Performance Low Power Lab

University of Virginia

Phone: 913-775-2241

On Mar 31, 2014, at 12:49 PM, Bogdan Diaconescu <address@hidden> wrote:

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 <address@hidden> wrote:

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

signature.asc
Description: Message signed with OpenPGP using GPGMail