Hi Marcus,
On Sun, Jun 1, 2014 at 2:44 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Mostafa, > > > You said the there is no problem that we wait on the source to produce > as long as we want! But this is not true when I have other blocks > waiting for processing!! > > Not true. If your block can't produce something, it's not GNU Radio's > fault your downstream blocks don't have anything to consume... > > This is not true because when I produce 1-3 packet of bits, the scheduler doesn't go to the other blocks while there is items for them! The scheduler calls the random bit generator for about 10 times!! > > In other word, when the source produces one packet, I want this > packet go down through blocks and amid of these blocks a message must > tells the source to produce again. > > This sounds like a bad design choice, why would a downstream block need > to tell the source to produce again? > I think we might have tried to convince you not to do this before, but I > just can't find the thread where you describe your problem. > > I think you're right. I would control something somewhere else. :) > > If the source doesn't produce anything after generating some packets, > the scheduler will be locked on the source and does nothing with other > blocks!! > > Exactly. If your source doesn't produce anything, your downstream blocks > can't consume anything -- there's nothing GNU Radio could do about this. > I'm fairly certain that GNU Radio will not stall a flow graph if there > is more than zero unprocessed items in the buffers. Haven't tested that, > though. Maybe someone else might comment on this. > So you have a logical deadlock, not a GNU Radio problem, if I understand > you correctly. > > > As you said, the *wait* will work for this source, but it's also has > the same problem I mentioned. > > Sorry, still don't undertand which problem you are writing about :( > > > I've read your code. There's absolutely no reason why the standard > behaviour of GNU Radio filling the output buffer of your source wouldn't > work -- these are pseudorandom numbers, > and there's absolutely no difference between generating e.g. 8192 at > once and producing them one at a time. > > > Greetings, > Marcus > > Müller <marcus.muel...@ettus.com> wrote: > >> Mostafa, > >> > >> I know you've been working many hours on this :) so don't worry, you're > >> being heard. > >> > >> Nevertheless, GNU Radio is surely not calling the asking the source > >> "crazily" to produce items. > >> > >> GNU Radio is a streaming-into-buffers architecture, which means that the > >> runtime will ask a source to produce output when there is space in the > >> output buffer. I fail to see the problem with this, since your source > >> can just take as much time as it wants to finish a work call, can > >> produce less than noutput_items, and generally should just be as fast as > >> it could. Not a single one of the items it produced is going to waste! > >> > >> It is good practice and done by *every* externally rate-limited source > >> to just block in work until enough items can be produced. If you need to > >> wait to get more random seed, well, then wait in work(). I admit, that > >> gets a little tricky when you want your seed to come in using a message, > >> because messages are not going to disturb your work due to design for > >> thread-safety. > >> > >> But then again, before I start proposing wait-notify/condition > >> multithreading methods, I'd like to hear a bit about your source and why > >> being called often is a problem; that's usually not the case, so chances > >> are we might help you find a solution if we understood what's wrong with > >> your source ;) > >> > >> Greetings, > >> Marcus > >> > >> On 01.06.2014 10:56, Mostafa Alizadeh wrote: > >>> Hi Mike, > >>> > >>> No, the throttle isn't a source! It just controls the flow of items in > an > >>> specific time interval. I don't want this! I want cognitively tell the > >>> source produces the random bits after some special procedures have done > >> (a > >>> message can do this for the source). But the scheduler crazily wants > the > >>> source to produce items! :) > >>> > >>> How could I deal with this problem? > >>> please. > >>> > >>> Best, > >>> > >>> > >>> > >>> On Sun, Jun 1, 2014 at 1:18 PM, Mike Jameson <mike.jame...@ettus.com> > >> wrote: > >>>> The "Throttle" block is required if you are not using any external > >>>> hardware: > >>>> > >>>> http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1throttle.html > >>>> > >>>> Mike > >>>> > >>>> -- > >>>> Mike Jameson M0MIK BSc MIET > >>>> Ettus Research Technical Support > >>>> Email: supp...@ettus.com > >>>> Web: http://ettus.com > >>>> > >>>> > >>>> On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh < > >> m.alizade...@gmail.com> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> I worked on GNURadio for many hours. After all, I prepared my blocks > in > >>>>> c++. However, the source by which I produce random bits (items with > >>>>> sizeof(char) ) doesn't work properly! By properly I mean, I wanted > >> GNURadio > >>>>> to lead me control how it's going to call the *source.* It's crazily > >>>>> calling the random bit generator so many times. > >>>>> > >>>>> I think this is because of the GNURadio's strategy for executing > blocks > >>>>> to achieve as maximum throughput as possible! So GNURadio translates > >> it* > >>>>> to call the source as much as possible*.(no matter what is the > source, > >>>>> here is the random bit generator) > >>>>> > >>>>> Am I right? If I am, what is the solution? > >>>>> > >>>>> Best, > >>>>> Mostafa > >>>>> > >>>>> _______________________________________________ > >>>>> Discuss-gnuradio mailing list > >>>>> Discuss-gnuradio@gnu.org > >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>> > >>>>> > >>> > >>> _______________________________________________ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > >> _______________________________________________ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
