Re: [Discuss-gnuradio] Broken gr_fir_fff ?

[madengr]

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.

----
address@hidden/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
address@hidden/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.









-- 
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.