End-to-end delay question

GNU Radio
1

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
aUuOaUuOuOuOaUuOuOaUuOaUuOuOaUuOaUuOuOuOaUuOaUuOaUuOuOuOaUaUuOuOuOuOaUuO
uOuOuOaUuOaUuOaUuOuOuOaUuOuOuOuOuOuOaUuOuOuOaUuOuOuOaUuOaUuOaUuOaUuOuOuO
uOuOaUuOuOaUuOuOaUuOuOaUuOuOuOuOaUuOuOuOuOaUuOaUaUuOaUuOuOaUuOuOuOuOaUuO
uOaUuOaUuOuOuOuOaUuOaUuOaUuOuOuOuOaUuOuOaUuOaUuOaUuOuOuOaUuOuOaUuOuOuOuO
uOaUuOuOaUuOuOuOuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOuOaUuOuOuOuOaUaUuOaUuOuO
uOaUuOaUuOaUuOuOaUuOuOaUuOaUuOaUuOuOuOaUuOuOaUuOuOuOuOaUuOuOuOuOuOaUuOuO
aUuOuOaUuOuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOuOuOaUuO
uOuOaUuOaUuOuOuOaUuOuOuOuOuOuOuOuOaUuOuOaUuOaUuOuOaUuOaUuOuOaUuOuOuOaUuO
aUuOaUuOaUuOaUuOuOuOuOaUuOaUuOuOaUuOaUuOuOuOaUuOuOuOuOuOuOuOaUuOuOuOuOaU
uOuOaUuOuOaUuOaUaUuOuOaUuOaUuOuOuOuOaUuOaUuOuOuOaUuOaUuOuOaUuOaUuOuOaUuO
aUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuOuOaUuO
uOuOaUuOaUuOuOaUuOuOaUuOaUuOuOuOaUuOaUuOaUuOaUuOaUuOaUuOuOaUuOaUuOaUuOuO
aUuOaUuOaUuOaUuOuOuOuOuOuOuOaUuOuOaUuOuOaUuOaUuOuOuOaUuOuOaUuOuOuOaUuOuO
aUuOuOuOuOaUuOaUuOuOaUuOuOuOuOaUuOuOuOuOuOaUuOuOaUuOaUaUuOaUuOuOaUuOuOuO
uOuOaUuOuOaUuOuOuOuOaUuOaUuOaUuOaUuOuOuOaUuOaUuOaUuOuOaUuOaUuOaUuOaUuOaU
aUuOuOuOuOaUaUuOuOuOuOuOaUuOuOuOaUuOuOaUuOaUuOuOuOaUuOaUaUuOaUuOaUuOuOaU
uOaUuO
[srb@radio usrp]$

2

On Mon, May 07, 2007 at 06:24:47AM -0500, Steve Bunch wrote:

At the end of that run, I turned on an analog radio tuned to the same
wonder what the semantics of stop() really are.

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

3

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:

At the end of that run, I turned on an analog radio tuned to the same
wonder what the semantics of stop() really are.

gr_fir_fff: using SSE

–
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(sig required by employer)

4

On May 7, 2007, at 8:49 AM, Eric B. 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

5

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

6

Also let me add that I believe only

usrp_wfm_rcv_pll.py

has the stereo decoder in it.

Bob

Bob McGwier wrote:

–
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

7

On Sun, May 20, 2007 at 02:13:37PM -0500, Steve Bunch wrote:

earlier than very recent indeed have a really ugly memory leak.
However, during this particular long USRP run, I was sitting at a
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 :wink:

Eric

8

On Mon, May 21, 2007 at 10:21:48PM -0400, Michael D. wrote:

On May 21, 2007, at 3:04 PM, Eric B. 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

9

On May 21, 2007, at 3:04 PM, Eric B. 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

10

On May 22, 2007, at 12:28 AM, Eric B. 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. :wink:

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

11

On Tue, May 22, 2007 at 10:59:22AM -0400, Michael D. wrote:

The midpoint would be (… + …) / 2. :wink:
Thanks. Fixed in the trunk.

implementation supports pthread_attr_setschedpolicy with SCHED_RR or
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

12

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

13

On May 22, 2007, at 11:46 PM, Eric B. 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 (&param, 0, sizeof (param));
param.sched_priority = priority;
int result = pthread_setschedparam (this_thread, policy, &param)
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(&param, 0, sizeof(param));
param.sched_priority = pri;
int result = sched_setscheduler(pid, policy, &param);
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

14

On Wed, May 23, 2007 at 10:30:32AM -0400, Michael D. wrote:

On May 22, 2007, at 11:46 PM, Eric B. 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

15

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 <pthread.h>
+
+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 (&param, 0, sizeof (param));
  • param.sched_priority = pri;
  • int result = pthread_getschedparam (this_thread, &policy, &param);
  • 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 (&param, 0, sizeof (struct sched_param));
  • param.sched_priority = pri;
  • result = pthread_setschedparam (this_thread, policy, &param);
  • }
  • 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
16

Hi all,

I know that there will be another burst of OFDM development work in the
coming weeks so just wanted to add some input that might be of interest
to
all.

We [Centre for Telecommunications Value-Chain Research] are using USRPs
for
our dynamic spectrum access and cognitive radio work. We’re not using
GNU
Radio, just the USRP and our own software. I’ve posted a video on
http://www.youtube.com/emergingnetworks showing the USRP in action with
reconfigurable OFDM operating at 2.35GHz. We have successfully
demonstrated
a live OFDM txrx link between two USRPs so it is definitely possible
over a
6-10 feet range even with only 50mW peak tx power (in fact, we have
achieved
this with a lot less power).

We are doing a lot of collaborative work with Tom R. in VT. As part
of
this, one of the demonstrations involves making a gap in the middle of
the
OFDM spectrum for a narrowband signal (the dbpsk signal from the
benchmark_tx.py script for example). The idea is to demonstrate that
coexistence between multiple users on the same spectrum segment is
possible.
The video shows how OFDM can be ‘sculpted’ to achieve this. I have a
much
better resolution video of this if anyone wants to take a closer look as
youtube has compressed it a lot, please let me know if you want it.

This is a 1MHz total bandwidth OFDM signal using a 256 bin IFFT; the
number
of carriers is varied from 255 right down to zero and back again in
various
spectral configurations. I had a screen capture program running on the
laptop also, so anything greater was resulting in underruns (we’ve
demonstrated up to 4MHz bandwidth but don’t have the processing
horsepower
to do much with it)

On that webpage, there’s also a very quick tour of what Tom and CTVR
were
demonstrating during the recent IEEE DySPAN conference in Dublin. The
cameraman for that clip was sacked shortly afterwards but there is a
proper
video of all the demos in production.

Videos: http://www.youtube.com/emergingnetworks

Emerging networks webpage with more information:
http://www.emergingnetworks.info

Best wishes,
Keith

Keith Nolan Ph.D.
Emerging Network Architectures
Centre for Telecommunications Value-Chain Research (CTVR)
Rm. 1.17, Lloyd Building
University of Dublin,Trinity College
Dublin 2
Rep. of Ireland.
e: [email protected]
p: (+353) 1-896-8443
w: http://www.emergingnetworks.info
skype: cognitive_radio