|Subject:||Re: [Discuss-gnuradio] one thread is not always scheduled|
|Date:||Thu, 22 Aug 2013 13:11:50 -0400|
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();On Thu, Aug 22, 2013 at 9:29 AM, Tom Rondeau <address@hidden> wrote:
On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang <address@hidden> wrote:Yes. If you have more than 1 core, the thread-per-block scheduler will
> I'm running Michael Buettner's RFID program.
> 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?
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.
This sounds like a different problem then what you posted originally.
> 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
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.
Visit us at GRCon13 Oct. 1 - 4
> 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>
>> > 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,
>> Visit us at GRCon13 Oct. 1 - 4
|[Prev in Thread]||Current Thread||[Next in Thread]|