[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Realtime Scheduling Problem

From: Sabathy Mischa
Subject: Re: [Discuss-gnuradio] Realtime Scheduling Problem
Date: Mon, 4 Aug 2014 11:17:08 +0000

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.



From: address@hidden [mailto:address@hidden
Sent: Dienstag, 29. Juli 2014 16:06
To: Tom Rondeau
Cc: Sabathy Mischa; address@hidden; discuss-gnuradio-bounces+address@hidden
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 Rondeau wrote:

On Tue, Jul 29, 2014 at 9:13 AM, Sabathy Mischa <address@hidden> 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.




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.






Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]