Re: [Discuss-gnuradio] Broken gr_fir_fff ?
Eric Blossom wrote: On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote: It's unlikely that there's a problem in gr_fir_fff. What version of GNU Radio are you using? What OS, distribution and version? What hardware are you running it on? How much memory does the machine have? Is there anything interesting in /var/log/messages? Eric Using next branch of GNU Radio pulled on 12/3/10. Pulled latest UHD source same day. Using latest USRP2 firmware and bit file for UHD Fedora 14, 32 bit Dell M6500 Laptop with 4 GB RAM Nothing from /var/log/messages or from dmesg I've boiled it down to something more fundamental. I'm getting the same behaviour with the simplest of flow graphs.I can't seem to go faster than 2 Msps into a single 265 point FFT sink (using GRC) without samples halting after a few seconds. No over or under run messages, nothing. The GUI is responsive, but the data slow has halted. If I add on a filter I can't go past 1 Msps. With just a simple python script connecting a 10 Msps USRP2 source into a null sink, it drops to the console in a few seconds with no info. I can't sustain 20 Msps for more than 1 second. m...@lt6034239[~/gnuradio_apps]$ ./bwtest.py linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101203153352.9d13960 Current recv sock buff size: 5000 bytes m...@lt6034239[~/gnuradio_apps]$ Laptop is connected to USRP2 via a 1000 Mb switch; lights show traffic stops and USRP LED C turns off. Straight connection to laptop makes no difference. benchmark_rx_rate is clean until 25 Msps, at which point it calculates 23 Msps sustained. Firewall is disabled. top shows python at 200% CPU when running, then drops off the process list when flow graph stops. I did the net.core.rmem_max=5000 and me - rtprio 50 tweaks. Anyway, I could swear I was not having these problems a couple of weeks ago. I distinctly remember looking at the full 25 Msps bandwidth on an FFT sink. Of course that was with the stable GNU Radio release and non-UHD. -- View this message in context: http://old.nabble.com/Broken-gr_fir_fff---tp30355695p30366677.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Broken gr_fir_fff ?
Can you pull the latest gnuradio next branch? I reverted some changes with the tags until we can re-group. You may have run into an issue with the work function implementation. Let me know if that resolves the issue. -Josh On 12/05/2010 05:53 PM, madengr wrote: Eric Blossom wrote: On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote: It's unlikely that there's a problem in gr_fir_fff. What version of GNU Radio are you using? What OS, distribution and version? What hardware are you running it on? How much memory does the machine have? Is there anything interesting in /var/log/messages? Eric Using next branch of GNU Radio pulled on 12/3/10. Pulled latest UHD source same day. Using latest USRP2 firmware and bit file for UHD Fedora 14, 32 bit Dell M6500 Laptop with 4 GB RAM Nothing from /var/log/messages or from dmesg I've boiled it down to something more fundamental. I'm getting the same behaviour with the simplest of flow graphs.I can't seem to go faster than 2 Msps into a single 265 point FFT sink (using GRC) without samples halting after a few seconds. No over or under run messages, nothing. The GUI is responsive, but the data slow has halted. If I add on a filter I can't go past 1 Msps. With just a simple python script connecting a 10 Msps USRP2 source into a null sink, it drops to the console in a few seconds with no info. I can't sustain 20 Msps for more than 1 second. m...@lt6034239[~/gnuradio_apps]$ ./bwtest.py linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101203153352.9d13960 Current recv sock buff size: 5000 bytes m...@lt6034239[~/gnuradio_apps]$ Laptop is connected to USRP2 via a 1000 Mb switch; lights show traffic stops and USRP LED C turns off. Straight connection to laptop makes no difference. benchmark_rx_rate is clean until 25 Msps, at which point it calculates 23 Msps sustained. Firewall is disabled. top shows python at 200% CPU when running, then drops off the process list when flow graph stops. I did the net.core.rmem_max=5000 and me - rtprio 50 tweaks. Anyway, I could swear I was not having these problems a couple of weeks ago. I distinctly remember looking at the full 25 Msps bandwidth on an FFT sink. Of course that was with the stable GNU Radio release and non-UHD. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broken gr_fir_fff ?
Sorry if I can't provide any more debug info, I'm new and ignorant, but I updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now I'm getting two programs with duplicate failure in gr_fir_fff. They just dump back to the shell after 2 seconds with no debug info. Only thing I did in uhd_modes.py was add my ip addr to the uhd src, so I don't think it's modifications I have made. It was working fine last night, but I did update from the repo today. I made some modifications to usrp_flex_band.py to getting it working with the USRP2 and UHD However I made the same mods to usrp_flex.py and it works fine. usrp_flex_band.py uses a 40 channel filter bank which I reduced to 4, in an attempt to debug, since it was causing a core dump, but I think that's a separate issue of thread resources (see the third excerpt below). --- m...@lt6034239[/usr/local/src/gr-air-modes/src/python]$ ./uhd_modes.py -a -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes Setting gain to 30 Rate is 400 gr_fir_fff: using SSE m...@lt6034239[/usr/local/src/gr-air-modes/src/python]$ m...@lt6034239[~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes gr_fir_fff: using SSE m...@lt6034239[~/gnuradio_apps/pager]$ m...@lt6034239[~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30 linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_0001.20101201214203.8fc7521 Current recv sock buff size: 5000 bytes gr_fir_fff: using SSE terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::thread_resource_error ' what(): boost::thread_resource_error Aborted (core dumped) m...@lt6034239[~/gnuradio_apps/pager]$ -- View this message in context: http://old.nabble.com/Broken-gr_fir_fff---tp30355695p30355695.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Broken gr_fir_fff ?
On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote: Sorry if I can't provide any more debug info, I'm new and ignorant, but I updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now I'm getting two programs with duplicate failure in gr_fir_fff. They just dump back to the shell after 2 seconds with no debug info. It's unlikely that there's a problem in gr_fir_fff. What version of GNU Radio are you using? What OS, distribution and version? What hardware are you running it on? How much memory does the machine have? Is there anything interesting in /var/log/messages? If there are 100's of blocks in this graph, you may want to reduce the default stack size allocated for each thread. (Even if not used, the virtual address space is reserved.) # Output from an x86_64 machine running Fedora 13 $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63888 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 50 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited The default stack size is 10240k. You can probably reduce this to 4094k (or maybe 2048k) without a problem using: $ ulimit -Ss 4096 Using -S sets the soft limit, which means you can set it back up without being root: $ ulimit -Ss 10240 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
