Forum: GNU Radio one thread is not always scheduled

Bbea2eb2d92532b5226eacd0e5b472e0?d=identicon&s=25 Pengyu Zhang (Guest)
on 2013-08-20 16:26
(Received via mailing list)
Hi,

I build a signal processing pipeline on USRP: RX --> decoder -->
protocol
--> TX. I used STS scheduler to schedule those signal processing blocks.
When the amount of data that goes into the decoder module is larger than
a
fixed number, the decoder thread is scheduled to run for a while,
decodes
the initial part of the incoming data, and is not scheduled anymore
before
it finishes processing the rest of the incoming data.

I'm a bit surprised to observe that one thread is not always scheduled
by
the scheduler. Does anyone have some ideas on how to tackle this
problem?
Thanks.

Pengyu
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-08-20 17:06
(Received via mailing list)
On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang <zhangelsu@gmail.com>
wrote:
> the scheduler. Does anyone have some ideas on how to tackle this problem?
> Thanks.
>
> Pengyu


I don't follow. How many threads are run? You said 'not always' but
that doesn't make any sense. Are you sure it's not consistent between
runs? Are you sure you are always using the STS scheduler (and if so,
why?)?

--
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
Bbea2eb2d92532b5226eacd0e5b472e0?d=identicon&s=25 Pengyu Zhang (Guest)
on 2013-08-20 18:06
(Received via mailing list)
I'm running Michael Buettner's RFID program.

https://www.cgran.org/wiki/Gen2

This program has many blocks:

rx --> matched_filt --> command_gate --> agc --> to_mag --> to_mag,
center
--> mm --> tag_decoder --> self.reader --> amp --> to_complex --> tx

I'm always using the STS scheduler because that's the default
configuration
to run Buettner's program. Before running the program, we
specify GR_SCHEDULER=STS. Are there drawbacks of using STS scheduler?

If the amount of data that goes into the tag_decoder module is smaller
than
1000 bits, the whole program runs correctly because tag_decoder module
is
scheduled several times to process all the incoming data. If the amount
of
data is over 1000 bits, the tag_decoder module is scheduled several
times
to process the first 1000 bits. However, the tag_decoder module never
gets
a chance to be scheduled to process the rest of incoming data. Instead
of
tag_decoder module, only self.reader module is always scheduled at that
point.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-08-22 15:31
(Received via mailing list)
On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang <zhangelsu@gmail.com>
wrote:
> to run Buettner's program. Before running the program, we specify
> GR_SCHEDULER=STS. Are there drawbacks of using STS scheduler?

Yes. If you have more than 1 core, the thread-per-block scheduler will
distribute your blocks over multiple thread units. Also, the TPB
scheduler allows the use of stream tags and async message passing, but
this program doesn't use those.

> If the amount of data that goes into the tag_decoder module is smaller than
> 1000 bits, the whole program runs correctly because tag_decoder module is
> scheduled several times to process all the incoming data. If the amount of
> data is over 1000 bits, the tag_decoder module is scheduled several times to
> process the first 1000 bits. However, the tag_decoder module never gets a
> chance to be scheduled to process the rest of incoming data. Instead of
> tag_decoder module, only self.reader module is always scheduled at that
> point.

This sounds like a different problem then what you posted originally.
What does this have to do with launching multiple threads?

This sounds like a problem in some of the custom blocks from that
project that aren't handing the consume/produce model correctly.

--
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
Bbea2eb2d92532b5226eacd0e5b472e0?d=identicon&s=25 Pengyu Zhang (Guest)
on 2013-08-22 16:48
(Received via mailing list)
So you suggested that tag_decoder module stops after 1000 bit transfer
because of the incorrect consume/produce model used by the custom block
rather than the STS scheduler. The consume/produce model used by the
tag_decoder module is shown below. I will take a close look at the
consume/produce model in each block of the signal processing pipeline.

ninput_items_required[i] = noutput_items + history();
Bbea2eb2d92532b5226eacd0e5b472e0?d=identicon&s=25 Pengyu Zhang (Guest)
on 2013-08-22 19:13
(Received via mailing list)
Hi Tom,

Do you have some suggestions about how to debug the consume/produce
model?
For example, how could I verify that the amount of the data produced
meets
the requirement of the consumer. Thanks.

Pengyu
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.