Re: [Discuss-gnuradio] one thread is not always scheduled

[Tom Rondeau]

On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang <address@hidden> wrote:
> 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?

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


> On Tue, Aug 20, 2013 at 11:05 AM, Tom Rondeau <address@hidden> wrote:
>>
>> On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang <address@hidden>
>> wrote:
>> > 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
>>
>>
>> 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