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

[Mostafa Alizadeh]

Hi Marcus, 

By mentioning that I spent many hours I wanted to say I'm hardly stuck on this problem yet! :)

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!! 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. 

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!!

As you said, the wait will work for this source, but it's also has the same problem I mentioned. 

Here is the summary of random bit generator:

#include <gnuradio/io_signature.h>

#include <stdlib.h>

#include <time.h>

#include <bitset>

#include <unistd.h>

namespace gr {

  namespace my_lte {

  lte_random_bit_gen::sptr

  lte_random_bit_gen::make(int packet_len) // packet_len: the size of generating packet bits 

  {

    return gnuradio::get_initial_sptr

      (new lte_random_bit_gen_impl(packet_len));

  }

  /*

   * The private constructor

   */

  lte_random_bit_gen_impl::lte_random_bit_gen_impl(int packet_len)

    : gr::sync_block("lte_random_bit_gen",

            gr::io_signature::make(0, 0, 0),

            gr::io_signature::make(1, 1, sizeof(char))),

      packet_length(packet_len),

  {

      srand (time(NULL)); // randomizing the seed

      set_max_noutput_items(packet_length);

  }

  lte_random_bit_gen_impl::~lte_random_bit_gen_impl()

  {

  }

  int

  lte_random_bit_gen_impl::work(int noutput_items,

            gr_vector_const_void_star &input_items,

            gr_vector_void_star &output_items)

  {

      char *out = (char *) output_items[0];

      int random_val, nout_written = 0;

          for (int i=0; i<packet_length; i++)

          {

              random_val = rand();

              bitset<8> b(random_val);

              if (b[0] == 0)

                  *out = 1;

              else

                  *out = 0;

              out++;

              nout_written++;

          }

                 // add tag

          add_item_tag(0,

                       nitems_written(0),

                       pmt::string_to_symbol("length"),

                       pmt::from_long(packet_length));

          cout << "bit generator " << endl ;

      return nout_written;

  }

On Sun, Jun 1, 2014 at 1:43 PM, 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