Yes, this solved my problems. Thanks. Alex On Mon, Dec 6, 2010 at 1:28 AM, Josh Blum <j...@joshknows.com> wrote: > 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: 50000000 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=50000000" 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
