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 On Thu, Aug 22, 2013 at 10:47 AM, Pengyu Zhang <[email protected]> wrote: > 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 <[email protected]> wrote: > >> On Tue, Aug 20, 2013 at 11:24 AM, Pengyu Zhang <[email protected]> >> 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 <[email protected]> wrote: >> >> >> >> On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang <[email protected]> >> >> 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 >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
