[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] what drives noutput_items passed to forecast?

From: George Nychis
Subject: Re: [Discuss-gnuradio] what drives noutput_items passed to forecast?
Date: Sat, 01 Mar 2008 18:59:04 -0500
User-agent: Thunderbird (X11/20080227)

George Nychis wrote:
Eric Blossom wrote:

For blocks derived from gr_sync_block, gr_sync_interpolator and
gr_sync_interpolator the scheduler knows how to compute noutputs from
ninputs and vice versa, and thus chooses noutputs so as to maximize
the amount of data given to work subject to all other constraints.

For other blocks, there isn't a mechanism for mapping from ninputs to
noutputs, so it does a binary search calling forecast until it finds
the value that processes the most input subject to all other constraints.

The details are in gr_single_threaded_scheduler.cc

The two basic constraints are:

  how much input is available
  how much output space is available

There are additional constraints based on output_multiple, etc.

I'm trying to emulate buffers and call general_work() for gr_clock_recovery_mm_ff. I'm 99.99% sure that its output_multiple is 1.

I have a certain number of input items, and I start probing for noutput_items by starting at 8192 and cutting it in half each time forecast() tells me I need more input than I actually have.

Once I find an appropriate noutput_items, I pass the input with the total number of input items and noutput_items.

Instead of returning noutput_items from the block, I return 'ii', which is the value that would have been passed to consume(). I then remove this number of items from my input and use whats left to probe again until I reach noutput_items=1 and the total required input is greater than the input I have left.

But after a short while 'ii' becomes some really odd number such as -2147483646.... this obviously kills everything because consuming a negative number is bad.

Is there some other constraint that is less obvious? I'm using 16-byte aligned buffers, calling forecast() to ensure that what it returns is <= to the total input I have, and then call general_work.

I know I'm totally hacking around the system, but I'd appreciate any help if there's something obvious I'm missing.

I think I've got it... it doesn't enjoy when the number of input items needed is around equal to the total number of input items (~6 off or so).

- George

reply via email to

[Prev in Thread] Current Thread [Next in Thread]