Re: [Discuss-gnuradio] Broken gr_fir_fff ?

[Josh Blum]

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