Realtime Scheduling Problem

GNU Radio
1

Dear All,

I am running GNU Radio 3.7.3 on a Debian Wheezy System with XFCE
Desktop.
In the setup I have, a USRP N210 with a SBX daughterboard is used. The
USRP samples at 25 MSPS and pretty big processing chain in GNU Radio
takes place, which uses about 40 percent of every of the total 8 CPUS.
The realtime Scheduling worked once I did the steps described in the
UHD.
This worked now for several days.
Yesterday I tried to restart the GNURadio script, no error regarding
realtime scheduling appeared or any other one, but only one CPU was
used.
Of course this was not enough so I lost many samples.
Once I changed “realtime scheduling” to “off” it worked again. The only
command I did in between was a sudo apt-get update which normally only
updates the packet list.
A restart of the PC did not helped. So at the moment I have no realtime
scheduling, but it seems to work so far.

Can anybody help me with this? Do I have to recompile GNU Radio? Had
somebody a similar issue? Realtime scheduling is only to maximize the
guarantee to get enough CPU resources right?

Thanks for the replies.
BR
Mischa

2

On Tue, Jul 29, 2014 at 9:13 AM, Sabathy M. [email protected] wrote:

The realtime Scheduling worked once I did the steps described in the UHD.
updates the packet list.

Thanks for the replies.

BR

Mischa

There is no reason that enabling realtime scheduling should affect the
scheduling of blocks among processor cores. The thread-per-block
scheduler
creates threads and leaves it up to your OS to distribute them properly
among the cores available for scheduling. So this sounds like an OS
issue.

For advanced control, you /can/ tell each block which cores it can use,
but
this would mean hand tuning everything. That can work and improve
results,
but becomes hardware-specific.

http://gnuradio.org/doc/doxygen/page_affinity.html

Tom

3

Was the flow-graph changed between restarts?

One mistake new users of Gnu Radio make is to create filters that have
an impossibly-high number of taps, which become choke points

where they consume a lot of CPU, make hardly any progress, and all the
downstream blocks starve for samples.

On 2014-07-29 09:55, Tom R. wrote:

This worked now for several days.

http://gnuradio.org/doc/doxygen/page_affinity.html [2]

Tom

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [1]

Links:

4

I have a rational resampler which takes a lot of resources, but this
worked so far with realtime scheduling.
So No I didn’t change anything like this between the restarts. The only
thing I changed was the RF Frequency of the N210. I also switched back
to the frequency I had before which was working with realtime scheduling
but the error stays as long as I have realtime scheduling enabled.

From: [email protected] [mailto:[email protected]]
Sent: Dienstag, 29. Juli 2014 16:06
To: Tom R.
Cc: Sabathy M.; [email protected];
discuss-gnuradio-bounces+mleech=removed_email_address@domain.invalid
Subject: Re: [Discuss-gnuradio] Realtime Scheduling Problem

Was the flow-graph changed between restarts?

One mistake new users of Gnu Radio make is to create filters that have
an impossibly-high number of taps, which become choke points

where they consume a lot of CPU, make hardly any progress, and all the
downstream blocks starve for samples.

On 2014-07-29 09:55, Tom R. wrote:
On Tue, Jul 29, 2014 at 9:13 AM, Sabathy M.
<[email protected]mailto:[email protected]> wrote:
Dear All,

I am running GNU Radio 3.7.3 on a Debian Wheezy System with XFCE
Desktop.
In the setup I have, a USRP N210 with a SBX daughterboard is used. The
USRP samples at 25 MSPS and pretty big processing chain in GNU Radio
takes place, which uses about 40 percent of every of the total 8 CPUS.
The realtime Scheduling worked once I did the steps described in the
UHD.
This worked now for several days.
Yesterday I tried to restart the GNURadio script, no error regarding
realtime scheduling appeared or any other one, but only one CPU was
used.
Of course this was not enough so I lost many samples.
Once I changed “realtime scheduling” to “off” it worked again. The only
command I did in between was a sudo apt-get update which normally only
updates the packet list.
A restart of the PC did not helped. So at the moment I have no realtime
scheduling, but it seems to work so far.

Can anybody help me with this? Do I have to recompile GNU Radio? Had
somebody a similar issue? Realtime scheduling is only to maximize the
guarantee to get enough CPU resources right?

Thanks for the replies.
BR
Mischa

There is no reason that enabling realtime scheduling should affect the
scheduling of blocks among processor cores. The thread-per-block
scheduler creates threads and leaves it up to your OS to distribute them
properly among the cores available for scheduling. So this sounds like
an OS issue.

For advanced control, you /can/ tell each block which cores it can use,
but this would mean hand tuning everything. That can work and improve
results, but becomes hardware-specific.

http://gnuradio.org/doc/doxygen/page_affinity.html

Tom

Discuss-gnuradio mailing list

[email protected]mailto:[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

5

I found out what caused my problem.
Indeed it was a problem with the number of filter taps.
This is the status:

  •      In the past three weeks it worked with a high number of taps

in realtime mode.

  •      This changed, only non-realtime mode but with same qty of

taps was working after the three weeks.

  •      This changed again today, I changed to half number of taps

and it worked again once even in realtime mode.

  •      I had to restart it and again it stopped again working. I had

to half the number of taps again to make it work.
(btw the filtering happens in the resampler)
So in the past it worked with four times higher number of taps and now
this is not anymore possible. In the OS nothing changed (no updates or
additional packets).

Does somebody has an idea what causes this? Restarts of the PC didn’t
help.

Thanks for replies.
Mischa

From: [email protected] [mailto:[email protected]]
Sent: Dienstag, 29. Juli 2014 16:06
To: Tom R.
Cc: Sabathy M.; [email protected];
discuss-gnuradio-bounces+mleech=removed_email_address@domain.invalid
Subject: Re: [Discuss-gnuradio] Realtime Scheduling Problem

Was the flow-graph changed between restarts?

One mistake new users of Gnu Radio make is to create filters that have
an impossibly-high number of taps, which become choke points

where they consume a lot of CPU, make hardly any progress, and all the
downstream blocks starve for samples.

On 2014-07-29 09:55, Tom R. wrote:
On Tue, Jul 29, 2014 at 9:13 AM, Sabathy M.
<[email protected]mailto:[email protected]> wrote:
Dear All,

I am running GNU Radio 3.7.3 on a Debian Wheezy System with XFCE
Desktop.
In the setup I have, a USRP N210 with a SBX daughterboard is used. The
USRP samples at 25 MSPS and pretty big processing chain in GNU Radio
takes place, which uses about 40 percent of every of the total 8 CPUS.
The realtime Scheduling worked once I did the steps described in the
UHD.
This worked now for several days.
Yesterday I tried to restart the GNURadio script, no error regarding
realtime scheduling appeared or any other one, but only one CPU was
used.
Of course this was not enough so I lost many samples.
Once I changed “realtime scheduling” to “off” it worked again. The only
command I did in between was a sudo apt-get update which normally only
updates the packet list.
A restart of the PC did not helped. So at the moment I have no realtime
scheduling, but it seems to work so far.

Can anybody help me with this? Do I have to recompile GNU Radio? Had
somebody a similar issue? Realtime scheduling is only to maximize the
guarantee to get enough CPU resources right?

Thanks for the replies.
BR
Mischa

There is no reason that enabling realtime scheduling should affect the
scheduling of blocks among processor cores. The thread-per-block
scheduler creates threads and leaves it up to your OS to distribute them
properly among the cores available for scheduling. So this sounds like
an OS issue.

For advanced control, you /can/ tell each block which cores it can use,
but this would mean hand tuning everything. That can work and improve
results, but becomes hardware-specific.

http://gnuradio.org/doc/doxygen/page_affinity.html

Tom

Discuss-gnuradio mailing list

[email protected]mailto:[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio