Re: [Discuss-gnuradio] More on latency

[Eric Blossom]

On Thu, Oct 21, 2010 at 02:23:20AM -0400, Marcus D. Leech wrote:
> On 10/21/2010 02:10 AM, Eric Blossom wrote:
> > On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote:
> >   
> >> I had a flow-graph that earlier today had a latency of roughly 1 second
> >> or so.
> >>
> >> When I tested it this evening, after it had been running for several
> >> hours, the latency was
> >>   back up to *several tens of seconds*!!!.  Which means that external
> >> events at the source take
> >>   several tens of seconds to show up at the sinks -- two graphical, and
> >> one filesink.  WTF? !!
> >>
> >> The CPU load at the time was modest -- about 38%
> >>     
> > 38% of what?  How many cores?  What kind of machine?
> >   
> A dual-core machine, an Atom D-510
> > It's possible that there's a computation in a single block that
> > requires > 1 core to compute in realtime.
> >   
> Unlikely.  The most "computey" block is a 1024-bin FFT, and my sample
> rate is only 400Ksps.
>   There's also an FFT filter, but it typically has only about 40-45 taps.
> 
> 
> > Have you tried oprofile to see where the graph is spending its time?
> > Are you i/o bound?  What's the rate that you're writing to the file sink?
> >   
> I'm writing to the file sink at 1Ksps.
> 
> There's also an audio sink, I'm using the "plughw:0,0" device, and it's
> being pumped at
>   20Ksps, which generally divides my source rate exactly.  I tried
> turning off that sub-tree
>   the other night, but I didn't let it run very long.  Perhaps a
> residual clock-rate mis-match
>   is causing 'buffer creep', and after a few hours, that 'buffer creep'
> has grown to several-10s
>   of seconds?

Yes, that would cause it.  I've seen it with the FM receiver apps.

BTW, it would have been useful to tell us that there was an audio sink
in the graph when you first posted the observation.

Thanks,
Eric