Re: [Discuss-gnuradio] More on latency

[Marcus D. Leech]

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?

> I believe htop will show you all the threads of the process.  Are any
> of them consuming on the order of 100% of a single core?
>
> Eric
>
>   
Hmm, have to check that.  OK, just installed 'htop' and there's no
single thread that's chewing on
  near 100% of a cpu.  The top two threads peak at around 70% and 30%,
but average somewhat
  less than that.

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