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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
