Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"

[Marcus D. Leech]

On 09/03/2010 11:52 PM, Eric Blossom wrote:
> The throttle block was written so that the GUI elements could be
> tested without an inherently rate limiting source being in the graph.
> It is not designed to precisely rate limit anything.  For any use
> other than that, you're asking for trouble.  Think about it:  what
> definitely of time to you use?  Over what period of time do you
> average, etc, etc.
>
>   
I understand that.  See below.

>
> It will do the right thing, assuming that all blocks "do the right
> thing" and compute as much output as they are asked to.
>
>   
> You don't send it at the right rate, you let the sink (or source)
> handle the timing issues.
>   
>
> Note that NONE of GNU Radio has any idea of the actual sample rate.
>
> There are some places where sample rates are used (e.g.,
> gr.sig_source), but they are there as a convenience so that people
> don't have to continually puzzle over normalized frequencies.
> However, this may give the impression that "sample_rate" actually
> means something in the real world, and it doesn't --- with the exception
> of i/o devices connected to a sample clock.
>
>   
Yes, I "get" that.

> The display may appear to run in "fits and starts" because the
> internal decimation rate of the sink may be too high for the throttled
> data rate that you're sending.  It may take a long time to get enough
> data for the FFT sink to display anything.  Or there could be bugs in
> the sink...
>
> E.g., the GL fft sink has at least a bug or two related to the
> mis-specification of python's '/' operator.  If you use integers,
> 1/3 == 0, but 1.0/3 = .3333   The bug I'm thinking of shows up as a divide
> by zero in the persistence code when the ftt sink is invoked with its
> default parameters (sample_rate = 1, fft_rate = 15).  There may also
> be problems with mapping the user provided fft_rate into the
> decimation factor of the keep_one_in_n block.  Not sure about that
> one, but this is a place where it's possible to ask for ill-specified
> behavior.  E.g., if I say that the fft_rate is 15, and my sample rate
> is 1, do I expect interpolation by 15???
>
>
> See Python PEP-238 for background on the divide issue and the use of
>
>   from __future__ import division
>
> to debork the behavior of '/', and possibly help fix the sinks.
>
>   
Thought about that, as well.  So replaced the graphical FFT sink with a
file sink, and set the
  "unbuffered" flag.  That file fills up in "fits and starts'--that is,
it spends quite a while with
  zero bytes in it, then really a lot of bytes, then no more bytes for
quite some time, then
  another lump of bytes, etc.  I confirmred that the "producer" end of
the FIFO was producing
  bytes at the correct rate.

So when I'm sending "real" data to an actual USRP (f'rexample), the
symbols will get clocked out at the right rate, provided
  that I issue those bits in sufficiently large lumps to prevent the
USRP from underrun on transmit.

But what about situations where you might have a source of bits that's
running in "real time" (like my little test case with the
  external FIFO), and you'd like the resulting symbols to be "clocked
out" at something resembling "real time"?  My test case
  was just a test case, but I can certainly imagine situations where it
actually matters.


> If you want to see the details of what the scheduler is doing,
> change
>
>   #define ENABLE_LOGGING 0
>
> to
>
>   #define ENABLE_LOGGING 1
>
> at the top of gr_block_executor.cc  It will then create a separate ASCII
> log file for each block.  They're named "sst-NNN.log".  The first line
> of each log identifies the block.
>
> Hope this helps!
>
> Eric
>
>
>   


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org