Re: [Discuss-gnuradio] End-to-end delay question
Here's my first cut at the realtime change for pthreads. This
compiles on OSX cleanly, and seems to work ... I enabled the printout
for now, as feedback for anyone trying "realtime" using pthreads. I
set the PRI to be 1/2 way between the current value and the max
(looks like 39). I changed the config/m4 file for grc_usrp to check
for "pthread_setschedparam" right after it checks for
"sched_setscheduler", since this looks like only place where this
routine is checked for in the GNU Radio config/m4 files. - MLD
% svn diff
Index: gnuradio-core/src/lib/runtime/gr_realtime.cc
===
--- gnuradio-core/src/lib/runtime/gr_realtime.cc(revision 5537)
+++ gnuradio-core/src/lib/runtime/gr_realtime.cc(working copy)
@@ -58,6 +58,42 @@
return RT_OK;
}
+#elif defined(HAVE_PTHREAD_SETSCHEDPARAM)
+
+#include
+
+gr_rt_status_t
+gr_enable_realtime_scheduling()
+{
+ int policy = 0;
+ int pri = 0;
+ pthread_t this_thread = pthread_self (); // this process
+ struct sched_param param;
+ memset (¶m, 0, sizeof (param));
+ param.sched_priority = pri;
+ int result = pthread_getschedparam (this_thread, &policy, ¶m);
+ if (result == 0) { // good results
+// set the priority half-way between the default and maximum
+pri = (sched_get_priority_max (policy) + param.sched_priority) / 2;
+
+int policy = SCHED_FIFO; // desired policy
+struct sched_param param;
+memset (¶m, 0, sizeof (struct sched_param));
+param.sched_priority = pri;
+result = pthread_setschedparam (this_thread, policy, ¶m);
+ }
+ if (result != 0) {
+if (errno == EPERM)
+ return RT_NO_PRIVS;
+else {
+ perror ("pthread_setschedparam: failed to set real time
priority");
+ return RT_OTHER_ERROR;
+}
+ }
+ printf ("SCHED_FIFO enabled with priority = %d\n", pri);
+ return RT_OK;
+}
+
// #elif // could try negative niceness
#else
Index: config/grc_usrp.m4
===
--- config/grc_usrp.m4 (revision 5537)
+++ config/grc_usrp.m4 (working copy)
@@ -52,7 +52,7 @@
# These checks don't fail
AC_C_BIGENDIAN
AC_CHECK_HEADERS([byteswap.h linux/compiler.h])
-AC_CHECK_FUNCS([getrusage sched_setscheduler])
+AC_CHECK_FUNCS([getrusage sched_setscheduler
pthread_setschedparam])
AC_CHECK_FUNCS([sigaction snprintf])
passed=yes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On Wed, May 23, 2007 at 10:30:32AM -0400, Michael Dickens wrote: > On May 22, 2007, at 11:46 PM, Eric Blossom wrote: > >pthread_attr_setschedpolicy is not the same thing as > >sched_setscheduler. It's for setting up the attribute that is passed > >pthread_create. > > Touché. Thanks for pointing that out ... should have been > "pthread_setschedparam()" instead. This routine is, if I'm reading > the MAN pages correctly, an exact parallel to "sched_setscheduler()", > but in pthread terms. Here's the basic code: That makes more sense. > Interestingly, at least on OSX 10.4.9, all policies have a (min,max) > priority of (15,47), and the default for any process is the mid-point > (31). Thus for OSX, "real time" priority needs to be closer to the > MAX than the mid-point. The default policy is "Other" (1), whatever > that is. They may be interpreted in different domains. That is, one range for each policy. I suspect that this is spelled out somewhere in the OS/X developer docs. SCHED_OTHER is the normal "time sharing" algorithm. The details will vary by implementation, but typically non-interactive or CPU bound processes are penalized relative to interactive processes. > But, again, for some reason 'configure' isn't registering that > pthreads are available on OSX 10.4 ... which they clearly are. - MLD Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On May 22, 2007, at 11:46 PM, Eric Blossom wrote:
pthread_attr_setschedpolicy is not the same thing as
sched_setscheduler. It's for setting up the attribute that is passed
pthread_create.
Touché. Thanks for pointing that out ... should have been
"pthread_setschedparam()" instead. This routine is, if I'm reading
the MAN pages correctly, an exact parallel to "sched_setscheduler()",
but in pthread terms. Here's the basic code:
---
int policy = SCHED_FIFO
pthread_t this_thread = pthread_self ();
int priority = (sched_get_priority_max (policy) +
sched_get_priority_min (policy)) / 2;
struct sched_param param;
memset (¶m, 0, sizeof (param));
param.sched_priority = priority;
int result = pthread_setschedparam (this_thread, policy, ¶m)
if (result != 0) {
printf ("Error %d doing 'pthread_setschedparam'.\n", errno);
...
---
Compare that with "gr_realtime.cc":
int policy = SCHED_FIFO;
int pri = (sched_get_priority_max (policy) +
sched_get_priority_min (policy)) / 2;
int pid = 0; // this process
struct sched_param param;
memset(¶m, 0, sizeof(param));
param.sched_priority = pri;
int result = sched_setscheduler(pid, policy, ¶m);
if (result != 0){
You'll notice that the 2 differences are (1) having to get the
current pthread instead of the PID; and (2) using
"pthread_setschedparam()" instead of "sched_setscheduler()".
Interestingly, at least on OSX 10.4.9, all policies have a (min,max)
priority of (15,47), and the default for any process is the mid-point
(31). Thus for OSX, "real time" priority needs to be closer to the
MAX than the mid-point. The default policy is "Other" (1), whatever
that is.
But, again, for some reason 'configure' isn't registering that
pthreads are available on OSX 10.4 ... which they clearly are. - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On Tue, May 22, 2007 at 10:59:22AM -0400, Michael Dickens wrote: > On May 22, 2007, at 12:28 AM, Eric Blossom wrote: > >The priority is set to the midpoint of the FIFO range, not maximized. > > My bad on the "maximized" ... but ... ummm ... no, not the midpoint > either the way it's written, if I understand the function calls > correctly. Here's the line: > > int pri = (sched_get_priority_max (policy) - > sched_get_priority_min (policy)) / 2; > > The midpoint would be (... + ...) / 2. ;) Thanks. Fixed in the trunk. > >I don't think we want to be creating new threads just to try > >to set real time scheduling. > > These changes are made to the current running thread, not to a new > thread, just like the code in "gr_realtime.cc". IMHO GNU Radio > already has enough threads, especially on OSX's implementation > because of Apple's weirdness of requiring separate threads for > callbacks on Audio and USB. > > >I strongly suspect that if a pthread > >implementation supports pthread_attr_setschedpolicy with SCHED_RR or > >SCHED_FIFO, then they will also implement sched_setscheduler with > >SCHED_RR or SCHED_FIFO. > > On OSX 10.4.9 (and, I would presume any 10.4.X): > sched_get_priority_max(), sched_get_priority_min (), SCHED_FIFO, and > "struct sched_param" [and "struct sched_param".sched_priority] are > defined in standard header files in /usr/include and seem to work as > required for modifying the scheduling priority and policy. > Strangely, the only part that's missing from headers is > sched_setscheduler() ... which gets divided and renamed to > pthread_attr_setschedpolicy() and pthread_attr_setschedparam(). pthread_attr_setschedpolicy is not the same thing as sched_setscheduler. It's for setting up the attribute that is passed pthread_create. The friendly manual says: NAME pthread_attr_getschedpolicy, pthread_attr_setschedpolicy - get and set the schedpolicy attribute (REALTIME THREADS) ... APPLICATION USAGE After these attributes have been set, a thread can be created with the specified attributes using pthread_create(). Using these routines does not affect the current running thread. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
Steve Bunch wrote: > 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.) Hello, This may explain some weird behavior I saw with USRP input overruns suddenly occuring several minutes after the start of a GNURadio program. Thanks. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On May 22, 2007, at 12:28 AM, Eric Blossom wrote: The priority is set to the midpoint of the FIFO range, not maximized. My bad on the "maximized" ... but ... ummm ... no, not the midpoint either the way it's written, if I understand the function calls correctly. Here's the line: int pri = (sched_get_priority_max (policy) - sched_get_priority_min (policy)) / 2; The midpoint would be (... + ...) / 2. ;) I don't think we want to be creating new threads just to try to set real time scheduling. These changes are made to the current running thread, not to a new thread, just like the code in "gr_realtime.cc". IMHO GNU Radio already has enough threads, especially on OSX's implementation because of Apple's weirdness of requiring separate threads for callbacks on Audio and USB. I strongly suspect that if a pthread implementation supports pthread_attr_setschedpolicy with SCHED_RR or SCHED_FIFO, then they will also implement sched_setscheduler with SCHED_RR or SCHED_FIFO. On OSX 10.4.9 (and, I would presume any 10.4.X): sched_get_priority_max(), sched_get_priority_min (), SCHED_FIFO, and "struct sched_param" [and "struct sched_param".sched_priority] are defined in standard header files in /usr/include and seem to work as required for modifying the scheduling priority and policy. Strangely, the only part that's missing from headers is sched_setscheduler() ... which gets divided and renamed to pthread_attr_setschedpolicy() and pthread_attr_setschedparam(). I've tested out these pthread calls, and they work quite nicely w/o needs for su or root execution. Shouldn't be difficult to create an "#elif" condition in gr_realtime.cc for those with pthreads ... but first the config m4 script for pthreads needs to work (at least on OSX): config.h has "/* #undef HAVE_PTHREAD */" ... I will look into these. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On Mon, May 21, 2007 at 10:21:48PM -0400, Michael Dickens wrote: > On May 21, 2007, at 3:04 PM, Eric Blossom wrote: > >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. > > Looking at gnuradio-core/lib/src/runtime/gr_realtime.cc, it seems > that the running thread's scheduling is set to FIFO and the priority > is maximized. The priority is set to the midpoint of the FIFO range, not maximized. > If this is "all" that's being done, then this can be ports to > pthread's (also supposedly POSIX), as on some BSD (and thus OSX) > systems. Instead of "sched_setscheduler" (which sets both the > scheduling policy and priority), use "pthread_attr_setschedparam" > and "pthread_attr_setschedpolicy". I will look into it. - MLD Michael, I don't think we want to be creating new threads just to try to set real time scheduling. I strongly suspect that if a pthread implementation supports pthread_attr_setschedpolicy with SCHED_RR or SCHED_FIFO, then they will also implement sched_setscheduler with SCHED_RR or SCHED_FIFO. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On May 21, 2007, at 3:04 PM, Eric Blossom wrote: 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. Looking at gnuradio-core/lib/src/runtime/gr_realtime.cc, it seems that the running thread's scheduling is set to FIFO and the priority is maximized. If this is "all" that's being done, then this can be ports to pthread's (also supposedly POSIX), as on some BSD (and thus OSX) systems. Instead of "sched_setscheduler" (which sets both the scheduling policy and priority), use "pthread_attr_setschedparam" and "pthread_attr_setschedpolicy". I will look into it. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
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
Re: [Discuss-gnuradio] End-to-end delay question
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
Hi Eric, Can you please give some examples/directions of/on data transceiver applications which you are using/available in GNU Radio repository? Thanks. Tarun On Tue, 8 May 2007 20:47:26 -0700, Eric Blossom wrote: Having the audio be non-blocking will stop the buffering/delay problem. The symptom that you see without it depends on which clock is faster. For example, we run data transceiver applications where there's no audio involved, where the total lateny in the system is on the order of a couple of milliseconds. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On Tue, May 08, 2007 at 05:01:49PM -0700, Steve R Bunch wrote: > >There is (was) a pretty substantial memory leak in wxWidgets/wxPython > >that has been fixed in some relatively new release. This would > >eventually cause problems (30 minutes or so). You can see if this is > >happening or not by watching the process size with ps. > > Thanks. Will check on this. > > >You can specify less buffering in the USB interface than the default > >(Actually, I'll change the default later today. This was causing a > >different problem for another application.) This will reduce the > >buffering in the interface to the USB to something like 32 kB. > > It takes a lot of buffering to get USB up into the multiple-second range, so > it seems like your change to the default should prevent that side from > getting too deep... > > >There is a general issue related to the fact that when using > >usrp_wfm_rcv and similar applications that there are in fact two clock > >domains, and that they are guaranteed not to match. There's an osc on > >the USRP and an osc associated with the sound card. We made an API > >change in the audio interfaces that can specify that it's NOT OK to > >block when accessing the audio interface. When used in a flow graph that > >contained both an audio sink or source and a USRP sink or source, this > >would result in the USRP being the master clock, and would dodge the > >"two clocks" problem. Although the parameter was added to all (most) > >audio interfaces, I believe that it currently only works on the > >portaudio interface. Please feel free to fix this for gr-audio-alsa, > >gr-audio-oss and gr-audio-osx. > > I understand the clock domain issue, hence was not too concerned > about the over/underruns related to the audio not running at exactly > the same clock rate as the USRP - though I didn't expect there to be > enough buffering in the pipeline to cause this much delay. However, > non-blocking the audio interface wouldn't prevent the (apparently > large) amount of stuff I see buffering up anywhere it can in the > pipeline in one direction (or, if not in that direction, then the > other...) unless you're lucky on which clock is faster. I'll go > look at the alsa code. Having the audio be non-blocking will stop the buffering/delay problem. The symptom that you see without it depends on which clock is faster. For example, we run data transceiver applications where there's no audio involved, where the total lateny in the system is on the order of a couple of milliseconds. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
>There is (was) a pretty substantial memory leak in wxWidgets/wxPython >that has been fixed in some relatively new release. This would >eventually cause problems (30 minutes or so). You can see if this is >happening or not by watching the process size with ps. Thanks. Will check on this. >You can specify less buffering in the USB interface than the default >(Actually, I'll change the default later today. This was causing a >different problem for another application.) This will reduce the >buffering in the interface to the USB to something like 32 kB. It takes a lot of buffering to get USB up into the multiple-second range, so it seems like your change to the default should prevent that side from getting too deep... >There is a general issue related to the fact that when using >usrp_wfm_rcv and similar applications that there are in fact two clock >domains, and that they are guaranteed not to match. There's an osc on >the USRP and an osc associated with the sound card. We made an API >change in the audio interfaces that can specify that it's NOT OK to >block when accessing the audio interface. When used in a flow graph that >contained both an audio sink or source and a USRP sink or source, this >would result in the USRP being the master clock, and would dodge the >"two clocks" problem. Although the parameter was added to all (most) >audio interfaces, I believe that it currently only works on the >portaudio interface. Please feel free to fix this for gr-audio-alsa, >gr-audio-oss and gr-audio-osx. I understand the clock domain issue, hence was not too concerned about the over/underruns related to the audio not running at exactly the same clock rate as the USRP - though I didn't expect there to be enough buffering in the pipeline to cause this much delay. However, non-blocking the audio interface wouldn't prevent the (apparently large) amount of stuff I see buffering up anywhere it can in the pipeline in one direction (or, if not in that direction, then the other...) unless you're lucky on which clock is faster. I'll go look at the alsa code. Thanks! Steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
On May 7, 2007, at 8:49 AM, Eric Blossom wrote: We made an API change in the audio interfaces that can specify that it's NOT OK to block when accessing the audio interface. [snip] Although the parameter was added to all (most) audio interfaces, I believe that it currently only works on the portaudio interface. Please feel free to fix this for gr-audio-alsa, gr-audio-oss and gr-audio-osx. IIRC: The "block" (3rd) parameter is valid and used correctly on gr- audio-osx. I do have some work to do on that component, and will add this to my "to be double-checked" list. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
Also let me add that I believe only usrp_wfm_rcv_pll.py has the stereo decoder in it. Bob Bob McGwier wrote: Steve: 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. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you're going to be crazy, you have to get paid for it or else you're going to be locked up." Hunter S. Thompson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] End-to-end delay question
Steve: 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. Bob 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. So what is the best way to flush the entire audio stream, end-to-end, from time to time? Or force the buffering to be minimized to reduce the total in the pipeline? I would have thought stopping the graph would drain it, but the recent email trail on stop() has made me wonder what the semantics of stop() really are. System is a dual-processor Pentium, CPUs running at about 30% utilization, running Fedora Core 6. Audio is default Alsa, on-board (ASUS motherboard) hardware. GNURadio version is 3.0, SVN'ed from the production tree a month or so ago. Steve Using RX d'board B: TV Rx >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE ** (python:2609): WARNING **: IPP request failed with status 1030 ** (python:2609): WARNING **: IPP request failed with status 1030 FYI: No Powermate or Contour Knob found aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUuOaUuOuOuOaUuOuOaUaUuOaUuOaUuOaUuOaUuOuOaUuOuOuOuOaUuOaUuOuOuOuOaUuOuOaUuOaUuOaUuOuOuOuOuOaUuOuOuOaUaUuOaUuOuOuOaUuOuOuOaUuOaUuOuOaUuOaUuOuOaUuOuOaUaUuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOuOaUuOuOaUuOuOuOuOuOuOaUuOaUuOuOuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOuOaUuOuOaUuOaUuOaUaUuOaUuOuOaUuOuOuOuOaUuOuOaUuOuOaUaUuOaUuOaUuOuOaUuOuOuOuOuOuOaUuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOaUuOaUuOuOuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOuOaUuOuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOaUuOaUuOuOuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOuOuOuOaUuOaUuOuOuOuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUaUuOaUuOaUuOuOaUuOuOuOuOaUuOaUuOuOuOuOuOuOaUuOuOaUuOaUuOaUuOuOuOuOaUaUuOuOaUuOuOaUuOaUuOaUaUuOaUuOuOaUuOuOuOaUuOuOuOaUuOuOuOuOuOuOaUuOuOuOaUuO aUuOuOuOuOuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOaUuOuOuOuOuOuOaUuOuOuOaUaUuOuOaUuOuOuOuOaUuOuOuOaUuOuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOaUuOaUuOuOuOaUuOaUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOuOuOuOaUuOuOuOaUuOuOuOuOuOuOaUuOaUuOaUuOuOaUuOaUuOuOuOaUuOaUuOaUuOuOaUaUuOaUuOuOuOaUuOaUuOuOaUuOuOuOaUuOuOaUuOuOuOuOuOaUuOuOuOuOuOaUuOuOuOaUuOaUuOuOuOaUuOuOaUuOuOuOuOuOuOaUuOuOaUuOaUaUuOuOaUuOaUuOuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOuOaUaUuOuOuOaUuOuOaUuOaUaUuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOaUuOuOaUaUuOuOuOuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOuOuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOaUaUuOaUuOuOaUuOuOaUuOuOuOaUuOuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOuOuOuOuOuOaUuOuOuOuOuOuOaUuOuOuOuOuOaUuOuOuOaUuOuOuOuOuOaUuOaUuOaUuOaUuOaUaUuOaUuOuOuOuOuOaUuOaUuOuOuOaUuOaUuOuOuOuOuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOaUuOuOuOuOuOuOaUuOuOaUuOaUuOuOaUuOuOaUuOaUuOuOuOaUaUuOuOuOaUuOuOaUuOuOaUuOuOuOaUuOaUuOaUuOaUuOaUuOaUaUuOaUuOaUuOaUuOuOuOaUuOuO uOuOuOuOaUuOaUuOuOaUuOuOaUuOuOaUuOaUaUuOaUuOuOaUuOaUuOuOaUuOuOuOaUaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOuOuOaUuOuOaUuOaUuOuOuOaUuOaUuOuOuOaUuOaUuOaUuOuOuOaUuOuOuOaUuOaUuOuOuOuOuOuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOuOuOuOuOaUuOaUuOuOuOaUuOuOaUuOaUuOaUuOaUuOuOuOaUuOuOuOuOuOuOaUuOaUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOuOuOuOuOaUuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOaUuOuOuOuOuOuOuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOuOaUuOuOaUuOaUaUuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOuOaUuOaUuOaUuOuOaUuOuOuOuOaUuOaUuOaUaUuOaUuOaUuOuOaUuOuOaUuOaUuOuOuOaUaUuOaUuOuOaUuOuOuOaUuOuOuOaUuOaUaUuOaUuOuOuOaUuOaUuOaUuOuOuOuOaUuOuOuOaUuOuOaUuOuOaUuOuOaUuOaUuOaUuOuOuOuOaUuOuOaUuOaUuOuOuOuOaUuOaUuOaUaUuOaUuOuOuOuOuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOuOaUuOuOaUaUuOaUuOuOuOuOaUuOuOuOuOaUuOuOuOuOuOaUuOaUaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOaUuOuOaUuOuOuOuOuOaUuOuOuOuOuOuOuOaUuOuOuOaUaUuOaUuOuOaUuOuOuOuOuOaUuOuOuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOaUuOuOuOaUuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOuOaUuOaUuOuOaUuOaUuOuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOaUuOaUuOuOuOaU uOuOuOuOaUuOuOaUuOuOuOaUuOuOaUuOaUuOuOuOaUuOuOaUaU
Re: [Discuss-gnuradio] End-to-end delay question
On Mon, May 07, 2007 at 06:24:47AM -0500, 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. > > So what is the best way to flush the entire audio stream, end-to-end, > from time to time? Or force the buffering to be minimized to reduce > the total in the pipeline? I would have thought stopping the graph > would drain it, but the recent email trail on stop() has made me > wonder what the semantics of stop() really are. > > System is a dual-processor Pentium, CPUs running at about 30% > utilization, running Fedora Core 6. Audio is default Alsa, on-board > (ASUS motherboard) hardware. GNURadio version is 3.0, SVN'ed from the > production tree a month or so ago. > > Steve > > Using RX d'board B: TV Rx > >>> gr_fir_ccf: using SSE > >>> gr_fir_fff: using SSE > There is (was) a pretty substantial memory leak in wxWidgets/wxPython that has been fixed in some relatively new release. This would eventually cause problems (30 minutes or so). You can see if this is happening or not by watching the process size with ps. You can specify less buffering in the USB interface than the default (Actually, I'll change the default later today. This was causing a different problem for another application.) This will reduce the buffering in the interface to the USB to something like 32 kB. There is a general issue related to the fact that when using usrp_wfm_rcv and similar applications that there are in fact two clock domains, and that they are guaranteed not to match. There's an osc on the USRP and an osc associated with the sound card. We made an API change in the audio interfaces that can specify that it's NOT OK to block when accessing the audio interface. When used in a flow graph that contained both an audio sink or source and a USRP sink or source, this would result in the USRP being the master clock, and would dodge the "two clocks" problem. Although the parameter was added to all (most) audio interfaces, I believe that it currently only works on the portaudio interface. Please feel free to fix this for gr-audio-alsa, gr-audio-oss and gr-audio-osx. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] End-to-end delay question
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. So what is the best way to flush the entire audio stream, end-to-end, from time to time? Or force the buffering to be minimized to reduce the total in the pipeline? I would have thought stopping the graph would drain it, but the recent email trail on stop() has made me wonder what the semantics of stop() really are. System is a dual-processor Pentium, CPUs running at about 30% utilization, running Fedora Core 6. Audio is default Alsa, on-board (ASUS motherboard) hardware. GNURadio version is 3.0, SVN'ed from the production tree a month or so ago. Steve Using RX d'board B: TV Rx >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE ** (python:2609): WARNING **: IPP request failed with status 1030 ** (python:2609): WARNING **: IPP request failed with status 1030 FYI: No Powermate or Contour Knob found aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU aUaUaUaUaUaUaUaUaUaUuOaUuOuOuOaUuOuOaUaUuOaUuOaUuOaUuOaUuOuOaUuOuOuOuOaU uOaUuOuOuOuOaUuOuOaUuOaUuOaUuOuOuOuOuOaUuOuOuOaUaUuOaUuOuOuOaUuOuOuOaUuO aUuOuOaUuOaUuOuOaUuOuOaUaUuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOuO aUuOuOaUuOuOuOuOuOuOaUuOaUuOuOuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOuO aUuOuOaUuOaUuOaUaUuOaUuOuOaUuOuOuOuOaUuOuOaUuOuOaUaUuOaUuOaUuOuOaUuOuOuO uOuOuOaUuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOaUuOuOaUuOaU uOuOaUuOaUuOaUuOaUuOuOuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOaU uOuOaUuOuOaUuOuOaUuOuOaUuOuOuOaUuOuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOuOuOuOaU uOaUuOaUuOuOaUuOaUuOaUuOuOuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOuOuOuOaUuOaU uOuOuOuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUaUuOaUuOaUuOuOaUuOuOuOuOaUuO aUuOuOuOuOuOuOaUuOuOaUuOaUuOaUuOuOuOuOaUaUuOuOaUuOuOaUuOaUuOaUaUuOaUuOuO aUuOuOuOaUuOuOuOaUuOuOuOuOuOuOaUuOuOuOaUuO aUuOuOuOuOuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOaUuOuOuOuOuOuOaUuOuOuOaUaUuOuOaU uOuOuOuOaUuOuOuOaUuOuOuOaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOaUuOaUuOuOuOaUuO aUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOaUuOuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOuO aUuOaUuOaUuOuOaUuOuOuOuOaUuOuOuOaUuOuOuOuOuOuOaUuOaUuOaUuOuOaUuOaUuOuOuO aUuOaUuOaUuOuOaUaUuOaUuOuOuOaUuOaUuOuOaUuOuOuOaUuOuOaUuOuOuOuOuOaUuOuOuO uOuOaUuOuOuOaUuOaUuOuOuOaUuOuOaUuOuOuOuOuOuOaUuOuOaUuOaUaUuOuOaUuOaUuOuO aUuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOuOaUaUuOuOuOaUuOuOaUuOaUaUuO aUuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOaUuOuOaUaUuOuOuOuOuOaUuOuOaUuOuOaUuOuOuO uOaUuOuOuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOuOaUuOaUuOaUaUuOaUuO uOaUuOuOaUuOuOuOaUuOuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOuOuO uOuOuOaUuOuOuOuOuOuOaUuOuOuOuOuOaUuOuOuOaUuOuOuOuOuOaUuOaUuOaUuOaUuOaUaU uOaUuOuOuOuOuOaUuOaUuOuOuOaUuOaUuOuOuOuOuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOaU uOuOuOuOuOuOaUuOuOaUuOaUuOuOaUuOuOaUuOaUuOuOuOaUaUuOuOuOaUuOuOaUuOuOaUuO uOuOaUuOaUuOaUuOaUuOaUuOaUaUuOaUuOaUuOaUuOuOuOaUuOuO uOuOuOuOaUuOaUuOuOaUuOuOaUuOuOaUuOaUaUuOaUuOuOaUuOaUuOuOaUuOuOuOaUaUuOaU uOaUuOaUuOaUuOaUuOaUuOuOuOuOuOaUuOuOaUuOaUuOuOuOaUuOaUuOuOuOaUuOaUuOaUuO uOuOaUuOuOuOaUuOaUuOuOuOuOuOuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOuOuOuOuOaUuOaU uOuOuOaUuOuOaUuOaUuOaUuOaUuOuOuOaUuOuOuOuOuOuOaUuOaUuOaUuOaUuOuOaUuOuOaU uOaUuOaUuOaUuOuOuOuOuOaUuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOaUuOuOuOuOuOuO uOuOaUuOaUuOuOuOuOaUuOuOaUuOuOuOaUuOuOaUuOaUaUuOuOaUuOaUuOuOuOuOaUuOuOaU uOuOuOaUuOaUuOaUuOuOaUuOuOuOuOaUuOaUuOaUaUuOaUuOaUuOuOaUuOuOaUuOaUuOuOuO aUaUuOaUuOuOaUuOuOuOaUuOuOuOaUuOaUaUuOaUuOuOuOaUuOaUuOaUuOuOuOuOaUuOuOuO aUuOuOaUuOuOaUuOuOaUuOaUuOaUuOuOuOuOaUuOuOaUuOaUuOuOuOuOaUuOaUuOaUaUuOaU uOuOuOuOuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOuOaUuOuOaUaUuOaUuOuOuOuOaUuOuOuOuO aUuOuOuOuOuOaUuOaUaUuOaUuOuOuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOaUuOuOaUuOuOuO uOuOaUuOuOuOuOuOuOuOaUuOuOuOaUaUuOaUuOuOaUuOuOuOuOuOaUuOuOuOaUuOuOuOuOaU uOaUuOuOaUuOaUuOuOuOaUuOuOuOaUuOaUuOuOuOaUuOaUuOaUuOuOuOuOuOuOaUuOaUuOuO aUuOaUuOuOaUuOuOuOuOaUuOaUuOaUuOuOaUuOaUuOaUuOuOuOaU uOuOuOuOaUuOuOaUuOuOuOaUuOuOaUuOaUuOuOuOaUuOuOaUaUuOaUaUuOaUuOuOaUuOuOaU uOuOuOuOaUuOuOuOuOuOuOaUuOaUuOuOuOaUaUuOaUuOuOuOaUuOuOaUuOuOaUuOaUuOuOaU uOaUuOuOaUuOaUuOaUuOuOuOaUuOuOuOuOaUuOuOaUuOuOuOaUuOuOuOaUuOuOaUuOaUuOuO aUuOaUuO
