Re: [Discuss-gnuradio] Broken gr_fir_fff ?

[Alexandru Csete]

Yes, this solved my problems. Thanks.
Alex

On Mon, Dec 6, 2010 at 1:28 AM, Josh Blum <address@hidden> 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.
>>
>> ----
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>