One thread is not always scheduled

GNU Radio
1

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

2

On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Z. [email protected]
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

3

On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Z. [email protected]
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

4

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.

5

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

6

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();