# Realtime Scheduling Problem **URL:** \ **Category:** GNU Radio\ **Created:** [July 29, 2014, 3:37pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237 "2014-07-29T15:37:18Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [July 29, 2014, 3:37pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237/1 "2014-07-29T15:37:18Z")
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 ---
**Author:** ![Sabathy\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@Sabathy\_M](https://www.ruby-forum.com/u/Sabathy_M)\ **Post date:** [July 29, 2014, 3:57pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237/2 "2014-07-29T15:57:06Z")
On Tue, Jul 29, 2014 at 9:13 AM, Sabathy M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://gnuradio.org/doc/doxygen/page_affinity.html) Tom ---
**Author:** ![Sabathy\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@Sabathy\_M](https://www.ruby-forum.com/u/Sabathy_M)\ **Post date:** [July 29, 2014, 4:08pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237/3 "2014-07-29T16:08:08Z")
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](http://gnuradio.org/doc/doxygen/page_affinity.html) [2] > > Tom > > * * * > > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1] Links: ---
**Author:** ![Sabathy\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@Sabathy\_M](https://www.ruby-forum.com/u/Sabathy_M)\ **Post date:** [July 29, 2014, 4:37pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237/4 "2014-07-29T16:37:54Z")
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: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Dienstag, 29. Juli 2014 16:06 To: Tom R. Cc: Sabathy M.; removed\_email\_address@domain.invalid; 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. \ 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](http://gnuradio.org/doc/doxygen/page_affinity.html) Tom * * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Sabathy\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@Sabathy\_M](https://www.ruby-forum.com/u/Sabathy_M)\ **Post date:** [August 4, 2014, 1:18pm UTC](https://www.ruby-forum.com/t/realtime-scheduling-problem/231237/5 "2014-08-04T13:18:49Z")
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: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Dienstag, 29. Juli 2014 16:06 To: Tom R. Cc: Sabathy M.; removed\_email\_address@domain.invalid; 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. \ 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](http://gnuradio.org/doc/doxygen/page_affinity.html) Tom * * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)