Re: [Discuss-gnuradio] a criticism to GNURadio's scheduler!

[Mostafa Alizadeh]

Hi Marcus, 

On Sun, Jun 1, 2014 at 2:44 PM, Marcus Müller <address@hidden> 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 <address@hidden> 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 <address@hidden>
>> 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: address@hidden
>>>> Web: http://ettus.com
>>>>
>>>>
>>>> On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh <
>> address@hidden>
>>>> 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
>>>>> address@hidden
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>