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

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJTOaKxAAoJEM4gonekoZOsehUH/0AKFTgCCG510gpB/JtvauND
vazCv8qpzhTy2quqLW4PvHItm9+VkGS4va9O3ef0SK1yzE3rQnCTJqBMz9ai5Hb/
/id85bFEyGgwdZGIDYTIwif1QWB89xYY1dbxpUgSC46rp40X/il3DWfcRrwaQiFC
6IsDBYXphCacxBtfbs2knVYSrqX0UFprDx3IwZsI49JBdq5XnfAUMqIBx5ppKYbU
D3isyZdRbLSZQGEAgnvTW/OOAUOvg0ycg6C+iIamEDNfTCkgdH2DYjuNrpw+I49F
QxBMuovynSVB4tR2INBXSkA6VnCPQnFIzMcv5/SLTTrI+T5hsG8SyzlK9q+UneU=
=i0rz
-----END PGP SIGNATURE-----
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 <b_diaconescu@yahoo.com> 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 <tjt7a@virginia.edu> 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio