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: mle...@ripnet.com [mailto:mle...@ripnet.com] Sent: Dienstag, 29. Juli 2014 16:06 To: Tom Rondeau Cc: Sabathy Mischa; discuss-gnuradio@gnu.org; discuss-gnuradio-bounces+mleech=ripnet....@gnu.org 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 <msaba...@hsr.ch<mailto:msaba...@hsr.ch>> 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 Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
