Re: [Discuss-gnuradio] End-to-end delay question

[Eric Blossom]

On Sun, May 20, 2007 at 02:13:37PM -0500, Steve Bunch wrote:
> >Steve Bunch wrote:
> >>I was listening to an FM station using
> >>usrp_wfm_rcv.py -f 93.1 -O pcm32k
> >>
> >>After this had been going on for a couple of hours, the output on the 
> >>screen showed a large number of over/underruns (complete output 
> >>pasted at the bottom to make it easy to discard), which were coming 
> >>out through the entire session. This amount of over/underrun is a 
> >>fairly new thing, haven't seen this much before, don't know what 
> >>changed, but that's a side-issue to my question.
> >>
> >>At the end of that run, I turned on an analog radio tuned to the same 
> >>station, and there was a 2-3 second time difference between the two 
> >>audio outputs. Assuming this was buffered in the audio system, that's 
> >>100K samples or so. If you were using the USRP audio output to listen 
> >>to a ham band for a while, heard something you wanted to reply to, 
> >>and hit the PTT button, you'd be 2-3 seconds behind real time.
> 
> On May 7, 2007, at 8:33 AM, Bob McGwier wrote:
> 
> >I want to make sure you have a very late wxgtk installed.   Versions 
> >earlier than very recent indeed have a really ugly memory leak.  
> >Eventually this memory leak really puts the hurt on the entire system. 
> >  I am pretty sure this is your problem.
> 
> I made sure the wxgtk was up to date, and it was.  Watching system RAM 
> usage, it remains flat for hours at around 266MB (of a 1GB machine, 
> with swap disabled).
> 
> I did determine why the excessive overrun of the audio channel started 
> happening suddenly.  Normally, when working with GNURadio/USRP, I am 
> working at the display/keyboard of the Linux box that hosts the USRP.  
> However, during this particular long USRP run, I was sitting at a 
> different computer, connected in to this Linux box via X windows, doing 
> other (unrelated) things on it.  I was initially suspicious of X and 
> the network drivers, since I was hitting them very hard, but couldn't 
> force any problems in brief testing.
> 
> What I noticed eventually by accident was that the beagled background 
> process, which is enabled by default in Fedora Core 6, kicks in when 
> the console of the Linux box goes idle for a while (screen saver kicks 
> in), and wants to consume 100% of CPU time to index my files.  The CPU 
> scheduling interference with GNURadio, due to the default time-sharing 
> scheduling regime both were running under, was causing the audio 
> sinking to get behind.  Turning off the beagled default startup has 
> made the overrun problem disappear.  (As would running GNUradio with RT 
> scheduling priority, which I'd be doing in production use.)
> 
> I haven't had time to look at fixing the gr.*alsa sink code (it's on 
> the to-do list), but the python code is indeed requesting non-blocking 
> output.
> 
> Steve

Hi Steve,

Thanks for the detailed report.

We have the capability to request real time scheduling (currently only
on systems that implment POSIX sched_setscheduler), but generally
avoid it by default, since folks have been known to frequently blow
their own feet off.

If you want to play with it, try

    # Attempt to enable realtime scheduling
    r = gr.enable_realtime_scheduling()
    if r == gr.RT_OK:
        realtime = True
    else:
        realtime = False
        print "Note: failed to enable realtime scheduling"


You'll need to be running as root, or holding CAP_SYS_NICE (linux) for
this to work.  You'll also need a reliable way to kill the process
running with real time scheduling enabled ;)

Eric