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> 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 [2] > > Tom > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: ------ [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2] http://gnuradio.org/doc/doxygen/page_affinity.html
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
